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TITLE: NON PR£-AX7THE!!roXCATED KERBEROS LOGON 

VIA ASYNCHRONOUS MESSAGE MECHANISM 



FIELD OF THE II 



nON: 



This disclosure relates to software mechanisms 
for authenticating a client or principal of a Kerberos 
domain. 



5 CROSS-REFERENCES TO RELATED APPLICATIONS 

This disclosure is related to the following co- 
pending applications, entitled: 

MESSAGE CONTROL SYSTEM FOR MANAGING MESSAGE 
RESPONSE IN A KERBEROS ENVIRONMENT, USSN 08/884,413 filed 

10 June 22, 1997 now allowed; and SYNCHRONOUS MESSAGE 
CONTROL SYSTEM IN A KERBEROS DOMAIN, USSN 08/948,840 
filed October 10, 1997; EXPEDITED MESSAGE CONTROL FOR 
SYNCHRONOUS RESPONSE IN A KERBEROS DOMAIN, USSN 
09/026,746 filed Febaniary 20, 1998; ASYNCHRONOUS MESSAGE 

15 SYSTEM FOR MENU-ASSISTED RESOURCE CONTROL PROGRAM, USSN 
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08/884,418 filed June 22, 1997 now allowed; each of which 
are incoirporated herein by reference. 



BACKGROUND QF THE INVENTIOMt 
5 m recent years, great emphasis has been 

provided and applied in regard to ensuring the security 
of communications in networks of clients and servers. 
Cryptographic systems have been developed for inaintaining 
privacy of information that is transmitted across various 

10 communication channels. One type of cryptographic system 
often used is designated as a ^^symmetric crypto-system'' • 
These symmetric crypto- systems generally utilize 
electronic keys and can be somewhat cos^pared to physical 
security systems. An example of this would be the 

15 network where a message holding box has a single locking 
mechanism which has a single keyhole. Then one key 
holder can use his key to open the box and place a 
message in the box and then relock the box. Subsequently 
then, a second holder (who has an identical copy of the 

20 key) then unlocks the box and retrieves the message. 
Here the term ^^symmetric" indicates the situation where 
both Users have ^^identical keys''. 

In computer systems which are designated as a 
^^symmetric crypto-system'', the system requires that there 

25 be (i) an encryption function E; (ii) a decryption 
function D; and (iii) a shared secret key, K. in this 
situation, the ^K*' key is a unique string of data bits 
which apply to the encryption and decryption fiinctions. 

One particular example of the 

30 encipherment /decipherment function is the National Bureau 
of Standards Data Encryption Standard designated as DES. 
Another example is the Fast Encipherment Algorithm 
(FEAL) . In this situation, in order to transmit a 
message (M) with privacy, the sender must compute a 

35 ciphertext designated on the basis where C equals E 

(M,K). In this situation, the recipient terminal, upon 
receipt of the ciphertext C, then computes the message M 
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equal to D (C,K), enabling the recipient terminal to 
recover the message ''W. 

Again here, K Is the shared secret-key which 
functions such that a unauthorized terminal who copies 
the clphertext C, but who does not know the shared secret 
key K, will find himself unable to recover the message M« 
Here, the security is based on maintaining the secrecy of 
the key K. 

In addition to the above-mentioned symmetric 
crypto- systems'' there are also systems designated as 
"^Asymmetric Crypto-Systems'^ often designated as Public 
Key Crypto -Systems which provide other ways of encrypting 
information* They differ fr<»a symmetric systems, for 
exaixqple, in the physical sense, such that the message box 
has one lock, but also has two non- identical keys 
associated with it. Here, either key can be used to 
unlock the box to retrieve the message which was locked 
in the box by the other key. mils type of system could 
be made to operate such that keys must be used in a 
^^particular sequence", such that the box can be locked 
with one key and only then unlocked with the other key. 
This asymmetric type crypto-system is often designated as 
a ^^RSA'' system which refers to the names of authors 
Rlvest, Shamir, Adleman (RSA) in a paper described in 
pages 120-126 of Vol. 21 of CACM (Communications of the 
Association for CoBoputing Machinery), pxiblished in 
February 1978. 

In systems designated as Public Key Electronic 
Crypto- Systems, each operating entity or terminal has a 
private key M", which is only known to that particular 
entity or terminal. There is also a public key, '^eN'^ 
which is pxiblicly known. Here, once a message is 
encrypted with a User's public key, it can only be 
decrypted using that particular User's ^^prlvate key'', d. 
Conversely, if the message is encrypted with the User's 
^private key". it can only be decrypted using that 
User's ^^publlc key". 
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A Kerberos Seciirlty System is being used as a 
developing standard for authenticating network Users and 
is often used primarily in the UNIX community where it is 
useful because it functions in a multi -vendor network and 
5 does not transmit passwords over the network. 

Kerberos operates to authenticate Users, that 
is to say, it determines if a User is a valid User. It 
does not provide other security services such as audit 
trails. Kerberos authentication is based on ^^passwords" 

10 and does not involve physical location or smart cards. 

To implement Kerberos in the system, each 
computer in a network must run Kerberos software. 
Kerberos works by granting a ^^tickef which ticket is 
honored by all the network computers that are running 

15 Kerberos protocol. The tickets are encrypted, so 
passwords never go over the network in ^^clear texf and 
the Users do not need to enter their password when 
accessing a different computer. 

Since there is often a need to run Kerberos on 

20 every single computer in a network, this sometimes 
presents a problem for potential Users. Considerable 
effort and time may be involved in porting Kerberos to 
each different hardware platform in the network. 
Kerberos Users tended to be large networks which were 

25 furnished with extended expertise. Since such resources 
are not generally available to smaller networks, it is 
sometimes a problem to make it available to such smaller 
networks which cannot justify the cost and e3q;>ense. 

The primary benefit of Kerberos is that it 

30 prevents a password from being transmitted over the 
network . 

Kerberos networks are involved with the type of 
systems designated as symmetric crypto- systems'' 
discussed above. One type of symmetric crypto system is 
35 called the ^^Kerberos Authentication System''. This type 
of system was discussed and published on the Internet by 
J.T. Kohl and D.C. Neuman in an article entitled ^^The 
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Kerberos Network Authentication Service" which was 
PTiblished September 19, 1993 on the Internet HFC 1510* 
Kerberos uses synimetric key crypto- systems as a primitive 
and often uses the Data Encryption Standard (DES) as a 
inter-operability standard. Kerberos systems have been 
adopted as the basis for security service by the Open 
Software Foundations (OSF), Distributed Computing 
Environment (DCE) • Kerberos was designed to provide 
authentication and key-exchange, but was not particularly 
designed to provide digital signatures. 

Thus , networks require systems and methods for 
securing communications which provide a way for one User 
to authenticate itself to another User and additionally, 
these often require systems for securing communications 
which facilitate digital signatures being placed on a 
message to provide for non- repudiation. 

Kerberized environments involve the transmittal 
of messages, for example, from a server to a client which 
leads to several major problems in these networks. One 
problem involves the inordinate period of time that a 
client or a server is required to wait after requesting a 
response to a Kerberos command. As a result of waiting 
for a response, this causes the controlling software 
program or process, to wait so that any other clients or 
servers in the network requesting a service would also 
have to wait. 

Another typB of problem involved in Kerberos 
networks is that there is no existing method of returning 
unsolicited messages, generated synchronously or 
asynchronously from a Kerberos Server to a client or 
other server. 

The presently described system involves client 
authentication and validation communications which are 
passed or funneled through several software processes, 
such as system libraries. The problem often arises that 
if the authentication mechanism is only able to process a 
single request for authentication to completion, then 
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there would generally exist a waiting time or bottleneck 
while the processing requests are validated. Vhus, by 
using an asirnchronous message mechanism with various 
subtasks, these subtasks in various states can continue 
5 to be processed without waiting for a single request to 
be completely finished. This facilitates the processing 
of multiple requests from multiple clients who are 
requesting Kerberos authentication. 

Thus, the software method and system of the 

10 described mechanism indicates how the mechanism can 
authenticate a client or principal who is participating 
in a Kerberos domain using an asynchronous message 
process. The validation of the client's ability to 
participate is performed by a Kerberos server. The 

15 communications between the client and the server are 
perfoanned by passing special tyipes of messages using 
specialized protocols and the communications are 
facilitated by a message handling and processing model 
which employs the asynchronous capability. 

20 Thus, the present system and method provides a 

new arrangement where clients can be authenticated by a 
software process residing in a client server unit wherein 
there previously was no method for client authentication 
in a Kerberos domain via an asynchronous message process. 

25 
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SUMMARY OF THE INVENTIONS 

The present configuration provides a system and 
method involving the logon of none preauthenticated 
clients which use a Kerberos domain « A multiple nxunber 
5 of clients and principals are connected through a network 
cloud to a Kerberos Server and also to a client server 
(ClearPath NX server) • The Kerberos Server provides for 
the administration of Kerberos operations and also 
provides a Key Distribution Center. The client server 
10 utilizes a combination of elements which include a 
Kerberos Sizpport Library, a General Security Service unit 
axiA Master Control Program which utilize a Menu-Assisted 

isjfs 

III Resource Control Program and a Communication Management 

'fl System (COMS) which cooperate to provide credentials or 

iff 15 find credentials for each non-preauthenticated client in 

order that the client may logon to the system in order to 
k utilize the Kerberos domain. 

The authentication of the client or principal 
r;: who participate in a given Kerberos domain are 

20 authenticated by an asynchronous response message after 
validation of the client's ability to participate is 
performed by the Kerberos Server. Communications between 
client and server are performed by passing various 
classes of messages using various protocols which work on 
25 an asynchronous basis. 

It should be understood that if the 
authentication mechemism was only able to process a 
single request for authentication to completion, then 
there would exist a number of bottlenecks, since one 
30 request for authentication could hold-up many of the 
other requests for authentication. Thus, by using an 
asynchronous message mechanism with its subtasks, then 
various authentication cycles can operate and occur 
without having to wait for any one single request to be 
35 conqpletely finished. As a result, there is an 

enhancement and facilitation of the processing of 
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multiple requests from multiple clients who request 
Kerberos authentication. 

The methodology of the present Invention 
enables asynchronous authentication of a non- 
5 preauthenticated single client in a Kerberos domain which 
services multiple clients, many of whom are requesting 
authentication. Further, the method eliminates any hang- 
ups or hold-ups due to unfinished cycles occurring from 
other multiple concurrent authentication requests. 

10 



awk\ appl \ 04 14 7 OL . DOC 



9 



BRIEF DESCRIPTION OF THg D RAWINgS: 

Fig* 1 is a general overview of the Kerberos 
domain involving various clients euid servers in a 
network; 

5 Fig. 2 is a block diagram showing the elements 

involved in network relationship designated as 
client/ClearPath/Kerberos Server; 

Fig. 3 is a drawing of the elements involved in 
an asynchronous message model involving a Kerberized 
10 environment; 

Fig, 4 is a flow chart illustrating the steps 
involved when a client service request seeks a response 
from the Kerberos server and indicating the path steps 
(fl) through (k) for synchronous message response; 
15 Fig. 5 is a flow chazrt illustrating the steps 

involved when the request involves a program designated 
as message communication system HCS; 

Fig. 6 is a flow chart illustrating the Menu 
Assisted Resource Control Program process involved for 
O 20 asynchronous message handling as shown in Figs. 6A and 

Fig. 7 on sheets 7A and 7B is a drawing 
illustrating a stack sequence operational chart showing 
the operations involved in providing a message for 
25 delivery to a requester; 

Fig. 8 is a generalized overview of various 
channels for synchronous and asynchronous message 
response management; 

Fig. 9 shows the message array full word format 
30 for the ClearPath NX Server where Fig. 9 A shows the MARC 
message format, and Fig. 9B shows the MCS message format, 
while Fig. 9C illustrates the display message format; 

Fig. 10 is a schematic drawing of the Datacomm 
Queue Stack arrangement showing a linked list of 
35 available queue locations handled by the ClearPath MX 
Server; 
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Pig. 11 is a simplified view of the Kerberos 
realm using the Expedited Sj^chronous Message Process; 

Fig. 12 is an exploded view of the process 
steps involved in the Expedited Synchronous Message 
5 Response in a Kerberos realm. 

Fig. 13 is an illustration of the message array 
format for the type of Message Control Systems involving 
^^asynchronous" response operations; 

Fig. 14 is a diagram showing the word layout 
10 for the COMS (Communication Management System); 

Fig. 15 is a schematic drawing derived from the 
process steps of Fig. 12 to indicate the sequence of 
updating operations between the Kerberos Server and 
ClearPath MX Server in a synchronous response method and 
15 system; 

Fig. 16 is a drawing showing an overview of the 
Kerberos client authentication arrangement via the 
as3rnchronous message model; 

Fig. 17 is a generalized drawing showing an 
20 expansion of Fig. 16 by indicating the Digest Support 
Modules and Log File; 

Fig. 18 is a process diagram showing the 
interacting elements and illustrating the sequence of 
operations for authenticating a client or principal in a 
25 Kerberos domain with an asynchronous message process. 
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GLOSSARY OF TERMS: 



1. UDP (User Datagram Protocol ) - This is a 
communication protocol which is used as one of a niunber 
of '^standard'' methods of communicating information across 
a network. 

An extension of this is a UDP Port; a communication port 
which is used for UDP coimnunications • 

2. HLCN (Host LAN Connection ) - The ClearPath NX HLCN 
product provides the implementation of NetBIOS and IPX 
protocols that permit terminal services to the ClearPath 
NX Server over Netware. 

3. MCS (Message Control System ) - Programs (with 
special privileges) on ClearPath NX systems that control 
the flow of messages between terminals, application 
programs, and the operating system (MCP) . Reference 
Unisys ^^A Series DCALGOL Programming Reference Manual,'' 
May 1989/Form 5014574.380 (Release Mark 3.8.0) 

4. COMS " (Communications Management System ) - is a 
Unisys Message Control System that supports processing 
for a network on the Unisys ClearPath NX Server. 
Reference: Unisys A Series Coxmnunications Management 
System (COMS) Operations Guide. May 1989 1154523.380 

5. MARC (Menu Assisted Resource Control ) - The MARC 
window provides access to the MARC program. One of the 
functions of the MARC program is to handle network and 
session control and provide re<3uested information and 
system messages for COMS. The MARC window (program) is 
always in operation in COMS. Reference Unisys ^A Series 
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Menu-Assisted Resource Control (MARC)'' Unisys Operations 
Guide, February 1992/F03:m #8600 0404-100. (Release Mark 
4.0*0) 

6. GSS-API (Generic Security Service ) - Application 
Program interface) - This is the draft -standard interface 
application programs use to access available security 
services generically« The actual security services are 
provided by underlying mechanisms. Possible 
implementation choices for mechanisms include, but are 
not limited to Kerberos, Secure Sockets, DASS. The goal 
is that applications do not require any knowledge about 
the underlying mechanism in order to use it. Reference; 
GSS-API Version 2 on A Series Functional Design 
Specification 95132/3 Version C. Published iJuly 23, 1996 
by Unisys Corp. 

6a) DASS - A security mechanism using the x.509 
capabilities • 

6b) Secure Sockets - A security machwism that has 
growing popularity on the Internet. 

7. HLCNTS (Host LAN Connection Terminal Service ) - 
ClearPath NX terminal service product predicated on the 
underlying HLCN product. HLCNTS provides connection 
based commiinications between clients using Netware based 
IPX/NetBIOS and the ClearPath NX. Reference: Unisys Host 
LAN Coxmection Terminal Services (HLCNTS) 
0.1.4/Version D, iJune 26, 1995. 

8. Asynchronous Message (Definition #1) - a message 
(data in display or non-display format) which is 
generated by a concurrent independent process yet 
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requiring occasional synchronization and cooperation of 
other process (es). (Definition #2): - A message (data in 
display or non-display foannat) which was generated in an 
envirozunent where asynchronism of processes exists* 
5 Reference: ^' An Introduction to Operating Systems ^ by 
Harvey M. Deitel (Addison -Wesley Publishing Company) 
First Edition 1984. 

9. Synchronous Message #1 - A message (data in display 
or non-display format) which is generated by a concurrent 

10 process dependent upon its own environment. #2 - A 
message (data in display or non-display format) which was 
generated in an environment where synchronism of a single 
process exists. Reference: ^^ An Introduction to Operating 
Systems by Harvey M. Deitel (Addison-Wesley Ptiblishing 

15 Company) First Edition 1984. 

10 • Kerberos Support Libraary (KSL) - This library 
provides functions to support the various Kerberos 
message exchange protocols and a number of User 
administration fxinctions. It closely interacts with the 

20 GSS Library and other system software. Reference: A-EAM 
Kerberos Support Library - Functional Specification 
93187/3 Version C. Published March 6, 1997 by Unisys 
Corp. 

11 • Stack Capsulate - A ^^snapshot" or ^^outline" of a 
25 non-detailed process environment. For explanatory 

purposes, it is a mid-level overview of the processing 
environment highlighting events in a se<zuential order. 

^2. Dialog No. (Dialog Number) - MARC establishes 
Dialog (s) Ntambers on behalf of a client requesting 
30 services. A Dialog Number is the internal /external 
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nuniber associated with a client which is accessing 
(using) MARC. 



13. NX MOP Enviro3Mftent - Unisys Corp. sells computers 
under the name ^ClearPath". For explanatory purposes, 

5 the architecture is designated as the ClearPath NX. The 
ClearPath NX is packaged with both MOP environments (this 
is the XJHisys A Series E mode processor) and the ^jsn" 
Server side. The NX MOP Environment pertains 

specifically to the E mode processor side of the 
10 architecture exclusive of the NT Server side. 

14. Unsolicited Message - A message (data in display or 
^ non-display fozmat) which is generated by a concurrent 

process that is received by a concurrent independent 
(different) process. 

15 15. Transaction ID i.e., (TRANSACTIONJD) - The internal 
name given to a uniqtuely generated number passed from 
ip MARC to the KSL (Kerberos Support Library) identifying a 

clients service request. This number will then be 
attached by the KSL and in turn sent back to MARC such 

20 that MARC may route an asynchzx)nous message back to the 
appropriate client (originator) . 

16. Networking Host Software - Generalized term for 
software residing and functioning on the ClearPath NX 
which provides network communication capability. 

25 Software such as the Networking Support Library, Telnet, 
TCP/IP, HLCM, etc. would be *known" or thought of as 
Networking Host Software. 

17. IPX - A communications protocol "Internetwork Packet 
Exchange" * 
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18. COMS MSG Format - A message consistent with an 
agreed upon £ormat that COHS (Item #4 of Glossary) 
recognizes. A message containing a COMS header 
(information in an agreed upon location and format) and 

5 the message portion so that COMS may route the message. 

19. Key Distribution Center - Portion of the software 
residing on the Kerberos Server which processes tasks 
related to Key(s). A key is a signal code which can be 
used to access a message which would not ordinarily be 

10 accessible . 

20. K-Admin - Kerberos Administz^at ion/ Software on the 
if Kerberos Server responsible for configuration and User 
111 eu3ministration of the Kerberos Server. 

ip 21. DCWRITE - A function construct in DCALGOL used to 

15 construct miessages and pass messages to an MCS. (Item #3) 
H Reference: A Series DCALGOL Programming Reference Manual 

form #5014574.380 (May 1989) Page 3-13 and Section 5. 
Published by Unisys Corporation. 

22. NetWare - An operating system developed by Novell, 
20 inc. The NetWare operating system runs in a file sesrver 
and controls system resources and information processing 
on the entire network or Internetwork. Reference: 
**Conce2ts" Novell NetWare 3.12, Jtily 1993. Part Number 
100-001715-001 

25 23. station Transfer - ClearPath NX terminal service 
product predicated on an underlying Station Transfer 
Protocol. Reference: Unisys ^^A Series Station Transfer 
Changes for A-EAM,*' Fxmctional Design Specification 
95145/3 Version A, November 2, 1995 
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24. GSS-API Library - ClearPath NX support library 
providing services as defined in Item #6 above. 

25. UserPata - constitutes a miniature data management 
system that maintains a database called 

5 SYSTEM/USERDA.TAFXLE • The database defines valid Usercodes 
and contains various types of data concerning the User 
population on a particular ClearPath lax Server. 

26. Encryption Library - The DES (Data Encryption 
Standard) Support Library. The DES Encryption Support 

10 Library provides the various encryption algorithms which 
are needed by the Kerberos protocols. i^ccording to 
[RFC1510] any Kerberos implementation must, at a minimum, 

support the following encryption algorithm: 

DES/CBC/MD5 (DES encryption, using cipher block chaining 

15 mode with an MD5 checksum) . 

27. Directives Interface - A Directive Command is a 
feature of HARC which enables a system to create new 
commands and make them available to MARC Users. To 
implement a ^true' directive, the function of these 

20 commands is defined by writing a library of AL(30L 
procedures (within the KSL in this case). The DIRECTIVE 
command is used in MARC to associate a command name with 
the procedure. Thereafter, Users can use the new command 
in the same way as they use any other MARC command. 

25 Reference Unisys ^ A-EAM Kerberos Directive Commands , 
Functional Design, 95057/3 Version B, August 17, 1995. 

28. Master Control Program (MCP) - Unisys reference to 
^^ Burroughs Large Systems MCP Manual ^ - Release 3.5; 
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May, 19 85 /Copyright 1985 # Burroughs Corporation, Detroit, 
Michigan 48232. 

29. Event - An "^Evenf^ provides a means to synchronize 
simultaneously executing processes. An event can be used 

5 either to indicate the completion of an activity (this 
would be how Kerberos is using it, i.e., on the Kerberos 
Server; and EVENT is changed to a ''^Happened'' state and 
the KSL is made aware of this chemge, (in this case the 
response has been formed) or as an. interlock between 
10 participating programs over the use of a shared resource. 
Prom Unisys ^' A Series ALGOL Programming Reference Manual 
Volume 1: Basic Implementation ^^ Release Mark 3. 7 /July, 
1987; Form* 1169844. 

30. Credential Handle - A data structure that points to 
15 a unique instance of a credential. 

31. Kerberos Authentication - A standard protocol that 
verifies the identity of a client to a server. The 
verification occurs by the client obtaining credentials 
from a Ticket -Granting Server. These credentials provide 

20 proof of the client's identity to the server. 

32. Preauthentication - A client has obtained 
credentials before connecting to a server. 

33. Non-preauthentication - A client connects to a 
server without having obtained credentials beforehand. 

25 34. Principal - A client, server or service. 

35. Principal ID - A unique identifier used to name 
principals. 

awkXappl \ 0414 70L . DOC 



18 



36. Ticket -Granting Server - A trusted third-party 
server that authenticates clients and issue credentials 
that clients use to authenticate themselves to sezrvers* 

37* Credentials - A data structure issued by a trusted 
5 third party that uniquely identifies a client to a 
server. This data structure is encrypted such that only 
the server can decrypt it. Successful decryption of this 
data structure by the server verifies the identity of the 
client, since only the true client could have obtained 
10 the credential from the Ticket-Granting Server. 

38. GSS-cred-handle - A credential handle. A GSS handle 
is of type DOUBLE and is represented by two words. The 
first word of the handle has three components containing 
important piece of information about the handle. The 

15 second word is unused. O^e three key con^onents of a 
handle are its type, index and qualifier. The type of a 
handle can have three possible values, name-handle, and 
credential handle or a context handle. This is stored in 
bits 43 through 40 of the first word. The index of a 

20 handle represents the index in the GSS internal data set. 
This is stored in bits 39 through 20 of the first word. 
The qualifier represents a random number that makes the 
handle unique. This random number is generated while 
creating the handle. This is stored in bits 19 through 0 

25 of the first word. 

39- GSS-cred-tag - The GSS-cred-tag is the unique key by 
which GSS references the credential efficiently. 
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40. Mech.AdcSLCreGl - Vhis is a 6SS procedure that KSL 
calls to add a credential for the name-handle that is 
passed in. A new credential handle is created by 6SS and 
passed back to KSL. 

41. MCP_ADD_Credential - This is a GSS procedure that is 
called by the MCP when a new session is logged on. The 
HCP is handed a credential or context handle that is 
associated with the mix nxamber that was passed in* 

42 . Name-Handle - A Name-Handle is a handle representing 
a name that GSS knows about. The type field of this 
handle has the value for the name-handle, the index 
represents its index in the GSS internal tables and the 
qualifier makes the handle unique. 

43. Telnet - A standardized protocol that logically 
connects a terminal or terminal emulator running in a 
workstation to a server. After successfully connecting 
to the server that the client may directly issue commands 
to the server that the server interprets and responds to. 

44. Station Transfer - A Unisys proprietary protocol 
that logically connects a terminal or terminal emulator 
to remote Unisys A Series or ClearPath system. 

45. ASP-Handle_Internal ID is a GSS-API procedure that 
returns the local usercode associated with the handle 
that is passed in. Any type of handle - name handle, 
credential handle or context handle, can be passed in, as 
input to the procedure. MARC calls this procedure 
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passing in a credential handle and gets back the A-Series 
usercode to log the user onto the system. 



46. Intercomq - an array o£ message (s) which is 
5 shared by one or more processes or programs This ^^qpieue" 

would be managed by an external third party such as an 
MCS (and ultimately the MCP) . Processes or programs 
sharing this array of messages would be able to 
^^communicate'' via this queue, i.e., ^^Intercomq." 

47 . Queue Event Mechanism - A software module 
designed to produce various results based on the success 
or failure of a message or command being INSERTed into a 
queue. The result would be in the form of an EVENT which 
could be interrogated and would be found to have HAPPE23ED 
or NOT.HAPPENED. 

10 48. MCS Logger Describes a **f unction"' or ^set 

of functions'' whereby activities associated with an MCS 
(Message Control System) are logged in the system SUMiiOG 
residing on some readable/writeable media on the 
ClearPath MX Server. Examples of what would be logged in 

15 the system SDMLOG are tasks initiated or terminated under 
or through an MCSA, changes in status of tasks would also 
be logged. For a conqplete evaluation, see the Unisys A 
Series System Software Support Reference Manual Version 
Mark 3.7, July 1987 #1170016. 

20 49. Mix Ntimber - A ^^Mix Number^^ is a number 

assigned by the ClearPath NX Server which identifies a 
task, process, or library ntunerically such that 



awk\ appl \ 0 4 14 7 OL . DOC 



21 

task/process administration, resource allocation, etc • 
inay be perfoxmed by the MCP (Operating System) . 

50. DCSENradESSAGETOMCS - The name of a procedure 

which is exported from the MCP and is available as ^^re- 
5 enterent code" to the Kerberos Support Library. The 
function of this procedure is to transport or ^^send'' a 
message from the Kerberos Library to a specified MCS. 
For this implementation the MCS is COMS. This process 
occurs via an asynchronous mechanism. 
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GLOSSARY 

KERBEROS SECURITY A13Mim STRATI VE COMMANDS 



!• All commands are entered by the client with the 
Kerberos prefix of ^^KRB". 

5 2 • C^Miiands s 

(a) CLOCKSKEW s This command allows the ClearPath 
NX security administrator to set the allowable 
clock- skew used by the Kerberos protocol to 
accommodate variations in clocks on remote systems, 

10 when verifying a ticket. The default clock- skew 

value is 300 seconds. (Synchronous). 

(b) DEBUG : The DEBUG conomand does not reczuire 
special privilege for a User to inxjuire on the DEBUG 
option that is currently being set. DEBUG is used 

15 to obtain information about KAl^IN request (s), 

procedure entries and exits, etc. This is used as a 
diagnostic tool. (Synchronous). 

(c) DESTROY : When invoked the command writes zeros 
to the specified credentials cache containing the 

20 tickets and thereby destroying the tickets. The 

cache is removed. (Synchronous) • 

(d) INIT: Before Kerberos can grant tickets for 
access to the services of other principals in a 
network, the User must first log in to Kerberos to 

25 obtain a set of credentials consisting of a Ticket 

Granting Ticket (TGT) and a session key (provided 
the User has not already logged on to Kerberos and 
had the TGT forwarded to the ClearPath NX Server) . 
On the ClearPath NX Server, the KRB INIT command 
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provides the means for allowing a User to log into 
Kerberos to obtain the TGT. (Asynchronous) • 

(e) KeyTab : This command allows an appropriately 
privileged User to iziquire the application 

5 principals in the Key Table file on the ClearPath NX 

Server, but not the values of the keys associated 
with the application principals. (Synchronous)* 

(f) LIST ; Displays for a User the primary 
principal and Kerberos tickets held in the 

1 0 credential s cache • ( Synchronous ) . 

(g) LOAD : Allows an appropriately privileged User 
to load new configuration files into memory 
immediately or wait until the next Kerberos 
initialization. (By default files are loaded at 

15 initialization) • (Synchronous) « 

(h) PASSWORD S Allows the client to change his or 
her password. (Asynchronous). 

(i) PID: Permits the client to inquire on his or 
her own Principal.ID given his/her ClearPath NX 

2 0 Usercode . ( Asynchronous ) . 

(j) REALM : Returns the realm name for the local 
host • ( Synchronous ) • 

(1) REPLAY ; Allows the appropriately privileged 
User to inquire, enable, or disable the REPLAY 
25 detection option. (Synchronous) • 
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GSNEBAL OVERVIEW t 

A general overview of various aspects of the 
Kerberos domain messaging systems is shown in Fig. 8. 
This figure illustrates various sequences used for both 
5 synchronous message handling and for asynchronous message 
handling. Discussion of ^^asynchronous'' operations is 
provided to show the contrast to the presently described 
^^synchronous'' operations. 

AS seen in Fig. 8, the client 10 initiates a 
10 command transfer 90 to the COMS program 99 
(Communications Management System Program) . Here the 
COMS program partitions into two aspects, one of which is 
the pre-processing for the Menu Assisted Resource Control 
Program (MARC) and the pre-processing for the Message 
15 Control Systems Programs. 

One leg at marker 100 shows the use of the Menu 
Assisted Resource Control Program 40, while the other leg 
200 shows the use of the message control system program 
41m. 

20 Now, following the leg 100 marker, the M2KRC 

program 40 is invoked which program initiates via Marker 
101, the directives processes 300. The directives 
processes 300 is a software mechanism in MARC to identify 
and process a ^directive command". 

25 The directives process then operates at marker 

301 to contact the Kerberos Support Library 34. Now 
assuming that the system is operating on a synchronous 
message basis, the Kerberos Support Library 34 will 
operate at marker 202 requesting service on behalf of the 

30 MARC program 40. During this service request all 
previous process within this environment will wait for 
the service response from the Kerberos Service 20. 
Following marker 203 back to the Kerberos Support Library 
34 the response is returned. The Kerberos Sxspport 

35 Library 34 will operate at marker 102 to send the 
Kerberos response to the COMS program 103, which then at 
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marker 104, will contact the ISARC program 40 wliich will 
then use the marker 105 to reconnect to the COHS program 
103 with the processed message response which at marker 
106 will be conveyed to the multiplexer 5x, and thence at 
marker lOx conveyed back to the client 10. 

Now on the other hand, if this had been an 
^^asynchronous" message response, it would follow that the 
directives process 300 would at marker 301 connect to the 
Kerberos Support Library 34 which then, at marker 202, 
would contact the Kerberos Server 20 which would then 
respond at marker 203 back to the Kerberos Support 
Library 34. As £ui asynchronous process during the 
transfer of control at marker 202 to the Kerberos 
Server 20 all previous process in the process environment 
are notified, specifically the fSARC program 40 via marker 

102 through COiyES 103 via marker 104 that the response to 
its service request will be returned at a later time. 
Continuing with the original request the Kerberos Server 
20 now having generated the response passes the response 
via marker 203 to the Kerberos Support Library 34. The 
Kerberos Support Library 34 would then at marker 102, 
connect to the COMS program 103 which program would, at 
marker 104, connect to the MARC program 40, which would 
then at marker 105, communicate back to the COMS program 

103 which then at marker 106 would convey the message 
response to multiplexer 5x, which would then, using 
marker lOx, convey the Kerberos Message Response to the 
client 10* 

Now, looking on the Message Control Systems 
(MCS) operations originating from the COMS program at 
marker 99, it will be seen that at marker 200 the pre- 
processing will initiate the MCS program 41m, which then 
at marker 201 will connect to the directives process 300. 

The directives process operates at marker 301 
to contact the Kerberos Support Library 34. 

Now assiming that the command is a synchronous 
command^, then the Kerberos Support Library will operate 
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at marker 202 requesting service on behalf of the 
program 40. During this service request all previous 
process within this environment will wait for the sesrvice 
response from the Kerberos Service 20. Following marker 
5 203 back to the Kerberos Support Library 34, the response 
is returned. The Kerberos Support Library 34 will 
operate at marker 204 to send the Kerberos response over 
to the COMS program 205/ which then at marker 208 will 
convey the Kerberos message response to the multiplexer 

10 5X/ which at marker lOx will convey the synchronous 
message response back to the client 10. 

On the other hand, if the command involved were 
a "^asynchronous command'', then the MCS program 41m would 
connect at marker 201 to the directives processes 300, 

15 which at marker 301 would contact the Kerberos Support 
Library 34. As an asynchronous process during the 
transfer of control at marker 202 to the Kerberos Server 
20, all previous processes in the process environment are 
notified (specifically the MCS program 41m via marker 204 

20 through CONS 205 via marker 206) that the response to its 
service request will be returned at a later time. 
Continuing with the original request the Kerberos Server 
20 now having generated the response, passes the response 
via marker 203 to the Kerberos Support Library 34. 

25 alienee, using the asynchronous command 

situation, the Kerberos Support Library 34 would operate 
at marker 204 over to communicate with the COMS program 
205, which then at marker 206, would contact the MCS 
program 41m. Thence, the MCS program at laarker 207 would 

30 reconnect to the COMS program 205 which then would at 
marker 208, connect to the multiplexer 5x in order to 
return the asynchronous message command at marker lOx 
back to the client 10. 

At the bottom of Fig. 8 there is seen a nuxnber 

35 of notations and references to certain of the markers in 
Fig. 8. Thus, the marker 301 represents a Kerberos 
command to be responded to by either the Kerberos Support 
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Library 34, or the Kerberos Server 20. The znarker 102 
represents the command response for the MAKC message 
layout • 

Fig. 9 (9A, B, C) is an illustration of the 
5 full word format for the ClearPath MX Server, 13 of Fig. 
2. 

Referring to Fig. 8, it may be noted that the 
marker 105 is related to the seciuences of Fig. 6A and 6B 
which refer to the handling of asynchronous service 

10 requests from the HilRC program. 

Then again in Fig. 8, at the marker 207, this 
can be correlated to Fig. 5 (which is derived from Fig. 
4) and which involves the processes for handling the 
message control system request operations. 

15 If the message control system MCS used is that 

of MARC 40, this particular system uses a Transact ion_ID. 
In this case, the routing of axi asynchronous response 
message is done by COMS 42 through the MARC 40 program as 
is indicated in Figs. 6A, 6B for the sequence ""^C", of 

20 Fig. 4. 

On the other hand, the response message 104 may 
be routed in a separate channel shown in Fig. 8 through 
the COMS 42 over to the other MCS 41m and the queue 62 as 
indicated in Fig. 5 at the sequence ^^B'^. 

25 The channel for other types of Message Control 

Systems (MCS) will use the COMS program 42 and use an MCS 
number instead of the Transact ion_lD. 

The MCS 41m has a program with a queue 62 
defined with stacks shown in Fig. 10. The MCS channel 

30 does not generally have to worry about routing of the 
message, since there is generally a single User for that 
MCS program, while on the other hand, the MARC program 
may have a thousand Users and this requires a unique 
Transact ion_lD. The MCS system and channel (B of Fig. 5) 
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is considerably xoore versatile in that it could use 
several words, or could use neither of these and just use 
an MCS number* Additionally, the MCS channel could make 
use of all of the extra words or even more words if 
5 required in order to handle the possibility of thousemds 
of client Users. 

Thus, there are variety of channels for 
providing asynchronous response messages back to a client 
requester as seen by the above examples where the t/lARC 

10 program uses the Transaction_ID while on the other hand, 
the Kerberos response message may be handled on the other 
MCS system via COMS 42 using one word or multiple words 
or a combination of greater number of words to route a 
message to particular client Users. 

15 When non-asynchronous (synchronous) response 

messages are involved, the ^synchronous" response 
messages are normally routed as shown in Fig. 4 through 
steps a, b, cl, dl, e, fl, g, h, i, j, k, and L. 
However, certain response improvement will be indicated 

20 in connection with Figs. 12 and 14 sxxbsequently 
described. 

The present system and method involves the 
Kerberos realm or domain which denotes a number of hosts, 
servers and clients connected into a single 

25 administrative domain. The general concept for modules 
which are hosts, sezrv^ers or clients are often designated 
herein as ^^principals''. The term ^^principal" is a term 
used to denote a uniquely named client or server 
participating in a network environment. The Kerberos 

30 realm or domain is provided with a Kerberos Server which 
is a host-server responsible for Kerberos security. 
Clients are units which may reside in attachment to the 
network cloud or within the network cloud. The use of 
the term ^^cloud'=^ or the term ^^network cloud" is a term 
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often proposed by the Novell Corporation and used to 
designate interconnections in a network, 

The term ^^ClearPath" is used to denote a Unisys 
Corporation system network wherein different platforms 
may be connected together but are also provided with 
coinpatible communication protocols and services, 

A general overview of a network designated as a 
Kerberos realm or Kerberos domain is shown in Fig, 1, 
The realm or domain involves a number of principals which 
may be considered digital machines and wherein these 
principals involve clients or servers that are 
participating in the domain which is under the control of 
a particular Kerberos server. 

Thus, as seen in Fig, 1, there may be a series 
of clients or client-terminals designated 10a, 10b, 10c 
• lOn, These units are connected to a network 
cloud 16 and a communications connector 18, There are a 
number of uniqcue clients or servers 11, 12, and 13 which 
can be designated as principals. One of the principals 
such as principal 13, is seen having a UDP (User Datagram 
Port) port 15, which connects the third principal 13 to 
the Kerberos Server 20. The network cloud 16 is also 
connected to the communication connector 18 which is then 
connected to the Kerberos Server 20, The UDP port 15 is 
an acronym for the ^^User Datagram Protocol" port. The 
network cloud 16 is a generalized interconnection element 
which may indicate that various clients are residing in 
the network cloud, 

A ^realm'^ or a ^^domain'' may denote a number of 
host servers or clients and principals involved in a 
single administrative domain designated as a Kerberos 
domain. The Kerberos realm can be considered as a tBrm 
for modules participating in a Kerberos domain. There 
can also occur a number of different realms or domains 
which can be interconnected and which involve another 
level of complexity. 
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Fig* 1 could also have more than one Kerberos 
Server connected In with various network connections. 
The Kerberos Servers can CCTumunicate with each other and 
participate as part of the domain involved. 
5 Fig. 2 indicates the Kerberos Server network 

with an expanded view of the principal unit 13. Here, 
the client terminal 10 is connected to the communications 
connector 18 which enables it to coiranunicate and operate 
with various aspects of the principal 13 and the Kerberos 
10 server 20. 

The typical principal 13 (ClearPath NX Server) 
is shown with a number of the basic functional elements. 
The bus 18c from the communications connector 18 is seen 
connected to the UDP port 26 of the Kerberos server 20. 

15 The bus further provides connection to the principal 13 
via the IPX/NetBIOS (NetWare process) 54 and the TCP/IP 
unit 56. The hardware IPX/NetBIOS provides similar 
functions to TCP/IP 56. IPX is an Internetwork Packet 
Exchange Protocol developed by Novell that sends data 

20 packets to re<iuested destinations, i.e. workstations, 
servers, etc. NetBIOS and IPX provide the session, 
transport and networking layers of a protocol stack which 
handles communication between dissimilar systems. 

The TCP/IP 56 (Transmission Control 

25 Protocol /Internet Protocol is a protocol for Internet- 
work communication between dissimilar systems. 

The Ports module 52 provides an interface to 
the Telnet Unit 48, to the station transfer unit 46 and 
to the KLCNTS Unit 50. 

30 The Telnet 48 involves a package switching 

network that enables many different varieties of 
terminals and computers to exchange data. 

The station transfer network 46 functions to 
provide the necessary protocol for information transfer. 

35 The HLCNTS 50 is a unit which provides the 

fxinction of connection emd communication between Netware 
clients and ClearPath NX clients. 
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The client infozrination or message thus enters 
the principal 13 through the ports 52 and talks through 
the Telenet 48 and station transfer unit 46, through the 
DC ^XTE Unit 44 which calls on the program COMS which is 
5 the communications management system {COKS 42). This in 
turn then communicates or talks to MARC 40 which is the 
Menu- Assisted System Resource Control program. MARC 
and COMS are Unisys Corp. A-Series program fvuictions 
which were developed for the Unisys Corporation A-Series 
10 computer systems. When a client logs on to the A-Series 
systems, a call is made on the MARC, that is to say, the 
Menu-Assisted System Resource Control program. The MARC 
40 will function to call on the Kerberos Support Library 
III (KSL) 34 in order to initiate the proper security 

} I 15 f imctions . 

|i The library module 38 designated GSS-API 

connects the MARC program both to the Siipport Library 34 
2-^ and to a User data bemk 36. 

The encryption library 32 is connected to 
j!-: 20 service both the Keirberos Sxipport Library 34 and the GSS- 

p API library 38. 

The GSS-API library 38 serves the function of 
providing interface application programs to access 
available security services. 
25 Also shown is the MCP internal service provider 

33 which is part of the XTkiisys A-Series Master Control 
program (MCP) . This includes a queue management function 
module and a UDP port management module 15. The MCP 
Service Provider 33 connects to a series of ports and 
30 also to the Telnet 48, the HLCN 50 and the station 
transfer unit 46. Additionally, the MCP Service Provider 
33 (Fig. 2) is also connected as seen in Fig. 3 to COMS 
42 and to the MARC 40 via MCP 60 as well as the Kerberos 
Support Library 34. 
35 There are several functions that are provided 

Toy the MCP 60, but the major functional concerns are 
those which involve the passing of an asynchronous 
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message in addition to handling the queue management 
functions and management of the UDP port 15 in the 
principal 13. (ClearPath MX Server)* 

The client 10 enters his communications via the 
5 communication connector 18 and bus 18c over into the 
ports 52 and then talks through the Telnet unit 48 and 
the station transfer group 46. These units in turn call 
the COMS 42 which in turn talks or communicates with lyiARC 
40 (Menu Assisted System Resource Control program) • Both 

10 COMS and MARC are Unisys A-Series computer system 
functions described in the attached Glossary* 

Further regarding Figs. 2 and 3, the Kerberos 
Server 20 is seen to have a XTDP port 26, a Kerberos 
administrator K-ADMIN 24 unit and a Key Distribution 

15 Center 22 (KDC) . 

The function of the Key Distribution Center 22 
(KDC) is to act as a trusted third party authority that 
holds the secret keys for all the principals in a realm. 
The KDC provides two services designated AS and TGS. ^^AS 

20 denotes Authentication Service (AS): i.e., A service of 
KDC that verifies the authenticity of a principal. From 
^^ CvberSAFE Challenger Administrator's Guide ^^ Version 
5.2.5/April, 1995. 

The function of the K-ADMIN 24 is to provide a 

25 program to perform administration of a remote Kerberos 
principal database. TGS is Ticket Granting Service (TGS) • 
K-AZ»IXN is the part of the KDC that provides tickets when 
a client wants to access a server. From ^ CvberSAFE 
Challenger Administrator ' s Quide ^ Version 5.2.5/April, 

30 1995. 

The UDP port 26 functions to handle the User 
Datagram Protocol. 

It may be noted that the UDP port 26 of the 
Kerberos server is provided with a communication line 18c 
35 through the TCP/IP 56 to the internal UDP port 15 (Fig. 2) 
of the principal 13 via bus 15b. 
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The two UDP ports (15 and 26) are two separate 
entities and reside in different machines. Each 
principal would have its own UDP port which then provides 
a special communications line to the Kerberos server, via 
the Kerberos server's UDP port, 26 (Fig, 2). 

The principal 13 unit shown in Fig« 2 is also 
sometimes designated as a ClearPath NX server and 
describes one specific type of a principal 13. 

Fig, 3 is a drawing showing the message model 
in a Kerberized environment. The client terminal 10 is 
here connected to the network connector 18 which provides 
a connection on bus 18k to the Kerberos server 20 and a 
coxmection on the bus 18c to the principal 13. This 
particular principal 13 is a specialized tmit designated 
as the Unisys ClearPath NX. The Unisys ClearPath HMP 
(Heterogeneous Multiprocessing System) acts to integrate 
a number of platforms such as UNIX, windows NT and 
Enterprise operating system environments by combining 
them into one platform. 

Within the principal 13, Pig. 3, there is seen 
the port's interfaces 52 which connect to the combination 
unit 50c designated as Telnet/HLCN/ Station Transfer. The 
HLCN refers to the high-level communication network. The 
combination module 50c then connects to the CONS 42 
programs (Communications Nanagement System) and also the 
MARC programs 40 (Menu Assisted Resource Control 
programs) • Then as seen, the MARC programs connect to 
the Kerberos Support Library 34. Further in Fig, 3, the 
Master Control Program MCP 60 is seen connected to the 
ports 52 the combination module 50c, the COMS program 42 
and the MARC program 40 and also the Kerberos Support 
Library 34. Each of the modules are connected to the 
MCP 60 (Master Control Program) , 

The Master Control Program 60 is shown to have 
two modules of which the queue management function module 
62 provides the function of managing an array of Queues 
shown in Fig, 10. 
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Additionally in the MCP 60, there is a UDP port 
inanagement unit 64. 

The Master Control Program 60 is seen in Fig. 3 
to have the queue management function module 62 which 
involves a Queue data structure which is shown in Fig. 
10. AS an analogy, the queue could be thought of as a 
pipe. For example, considering that there is a person 
involved at each end of the pipe such that Person A at 
the left end of the pipe and Person B at the right end of 
the pipe. Then, at the halfway point of the pipe, there 
could be considered a Person C. Then for example. Person 
A weuits to move a ball (message) from one end of the pipe 
to the other* Person A with the ball, then asks Person C 
(halfway point) to tell Person B to wake up and notice 
that there is a ball coming down the pipe. Person C 
wakes up Person B and then tells Person A to insert the 
ball in the Pipe for delivery. Person C then moves the 
ball down the pipe and tells person B that "^Yes, okay the 
ball is now here''. 

In the above analogy, it can be considered that 
Person A is the COMS program, while Person B is any one 
of the various Message Control Systems (MCS), and 
likewise, the Person C would be analogous to the Master 
Control Program (MCP) . This is, of course, an over- 
simplified version, but it illustrates the role of the 
COHS program to the Message Control System programs (MCS) 
with the Master Control Program (MCP) acting as a 
^overseer /controller" . 

Queue Management Function 62 in the MCP 60 (Fig. 31 g The 
MCP 60 controls the operational environment of the system 
by performing the functions of job selection, memory 
management, peripheral management, virtual memory 
management, dynamic sxib- routine linkage, logging of 
errors, system utilization, and queue management. More 
specifically, the MCP 60 manages an array of queues. A 
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Stack called the Datacamm Queue Stack (Fig. 10) holds 
messages (data descriptors) and other hidden messages. 

The primary function of the Datacomm Queue 
Stack (Pig. 10) is to hold <iueues which are declared in 
5 DCALGOL language^ and to file input queues for programs 
with remote files. The Datacomm Queue Stack also serves 
as one possible communication link between the Master 
Control Program (MCP) and the «IR'' (Independent Runner) 
^^Controller . ^^IR" stands for ^^independent Runner" 
10 Controller which is a separate process that gets 
initiated during system initialization. This Controller 
handles functions such as Job Control (queuing of jobs, 
starting and stopping of jobs, operator command 
processing, etc.). The MCP initiates a number of '^XR's'' 
15 during initialization. A common name or nomenclature in 
the industry today would be to ^ spawn a separate 
process'^ . 

^ The Dataconmi Queue Stack is seen in Fig. 10. 

p The first word in the stack contains a TOSCW (Top of 

20 Stack Control WOrd), while the second word contains a 
1^^ link. 

This link is the start of a link list of 
available queue locations and is relative to ^^Word 1" of 
the stack. Locations in the stack that are not a part of 
25 this list are ^data descriptors'' that point to hidden 
messages. The "^hidden messages'" contain the head and the 
tail pointers of queue entries, plus attributes of the 
queue, such as the memory limit and the population. 

As messages are placed in the Datacomm queue, 
30 (Fig. 10) the queue's memory limit may be reached. In 
this case, if the queue's limit is reached, a Tank 
Information Block (TIB) is built, then disk rows are 
obtained with the procedures called GETUSERDISK and the 
subsequent messages for the queue are TANKED, that is to 
35 say, written to disk. it may be indicated that the queue 
messages will not be found in memory and disk at the same 
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time. They will either be queued on disk or in the 
memory, but not both. 

«Word One^ in the stack is the beginning of a 
linked list of available stack locations* Other 
locations will point to the ^^hidden message". The Tank 
Information Block (TIB) contains a variable number of Row 
Address Words. These Row Address Words point to the disk 
area. 

Further in Fig, 2, the network cloud 16 and 
com-coimector 18 are seen having coxmaunication busses 18k 
and 18c over to the Kerberos server 20 which has a Key 
Distribution Center Unit 22 and a Kerberos Administrator 
Unit 24. The Key Distribution Center Unit 22 functions to 
provide secret access signal codes (keys) to enable 
message access. 

The UDP port management unit 15, Fig. 3, 
involves the User Datagram Protocol (UDP) which is a 
TCP/IP protocol that permits an application to send a 
message to one of several other applications running in 
the destination machine. The "^^send message" Application 
is responsible for providing a reliable delivery of the 
messstge . 

In regard to the preliminary steps which lead 
up to and through a request for service so that there can 
be enabled the return of a synchronous or an asynchronous 
message in response to the client request, it will be 
seen that there are several assumptions which must be 
considered as residing in place before the detailed 
functioning of this model can be operative. These 
assumptions include: 

(i) The client or principal who is requesting a 
service must be recognized as a valid client or a 
valid principal within the Kerberos realm. 

(ii) By use of the word ^valid", the participant 
must already be logged on and be recognized within 
the Kerberos realm. The participant will have and 
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ABSTRACT OF THE DISCIiOSURE: 

TITLE: NON-PREAUTHENTICATED KERBEROS LOGON VIA 

ASYNCHRONOUS MESSAGE filECHANISM 

A method and system is provided wherein a 
multiple niamber of non-preauthenticated clients and non- 
preauthenticated principals are seeking to logon into a 
Kerberos domain. Normally^ such logon operations would 
be held-up and stopped until any one single client or 
principal had completed his logon authorization. However, 
the present system uses an asynchronous message mechanism 
by which any single non-preauthenticated client or non- 
preauthenticated principal can complete his initial logon 
operation without having to wait for another's 
authenticating logon operation to be completed. A series 
of asynchronous message mechanisms are provided in which 
any single client or principal can complete and finalize 
the authentication of his logon without having to wait 
for the completion of other requesting clients and 
principals seeking to logon and be authenticated. 
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be given all the rights that any other ^Kerberized'' 
client or principal might expect to have within the 
particular Kerberos Realm of participation. 

(iii) The individual data which moves between the 
5 Unisys NX server software will not be particularly 

described other than to indicate that the request 
was ^passed" to the next layer of software as 
appropriate. The data moves between various 
software packages in itself. A simple assunqption 
10 will be made that data "^^is passed'' between the 

software . 

Briefly, a client or principal must already 
have been ^logged on'' within a Kerberos Realm and thus be 
provided with the same privileges as that provided any 
Z 15 ^Kerberized" client or principal's esqpectation of 

privileges. 

The references made below to a client will, of 
course, assiame that the client or principal is 
participating in a Kerberos Realm. As a further 
20 assumption for this description, it will be assumed that 
0 there is a person or a client operator sitting at a 

personal computer (PC) with Kerberos privileges. 

Fig. 4 is a generalized flow chart indicating 
the operations occurring upon initiation of a service 
25 re(2uest by a client. The service request (a) shown in 
Fig. 4 comes into COMS (b) and COMS will view this as a 
request to HARC or to an HCS (Message Communication 
System) as seen in Fig. 8. The COMS program at (b) 
Fig. 4, will indicate that this was a request which was 
30 either a MARC request or a MCS request which is shown at 
block (cl) and block (c2), which is the MCS request. 

At position (b) of Fig. 4, where the COMS 
program routes the request to the MCS or the MARC, the 
term ^^routes" or the term ^^passes'' in this instance 
35 ix^plies that a request or a message is being xnoved via a 
queue (queuing structure) from one software stack to 
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another software stack. This move, via a queue, is 
accomplished by transferring the request or message data 
from one stack's envirozuoent, to another stack's 
environment (Fig. 10) by passing a ^data descriptor'' 
which points to an area in memory where the data can be 
found. The management of this function is provided by 
the HCP 60. This likewise applies to position (i) of 
Fig. 4 which indicates that the Kerberos Support 
Library 34 passes the response via giueue to the MARC 
program, 40. 
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Now referring to position (k) of Fig. 4 which 
indicates that the ^^MARC program returns the service 
requested, the term "^returns" ix^plies the use of a queue 
for communicating both through and to the COMS program 
5 which is an ancillary process occurring each time that 
Mi^C communicates outside of its stack environment. The 
MOP 60 provides low-level queue management functions with 
COMS providing the higher- level qpieue management 
functions. 

10 It is understood that when a client has made a 

service request, the client is communicating over the 
Fig. 3 communication bus 18c, then through the TCP/IP 
protocol 56 (Fig. 2) in order to access the COMS 
program 42. 

15 Now taking the leg (of Fig. 4) shown at (cl) 

which is the MZ^U^-request for Kerberos service, here 
there is provided a specialized process where the M2^C 
program requests service from the Kerberos Support 
Library (KSL) 34 at (dl) . Once the Kerberos Support 
20 Library receives a request for service, then a decision 
tree {^^A'M at position (e) of Fig. 4, is shown as 

decision tree ^^A'' which raises the question of is 

this going to be a ^'asynchronous message^' (yes, Y) or is 
this going to be a ^^synchronous'' message (no, M) . 
25 If the answer is ^no'' (N), that is to say, it 

is not an asynclironous message but merely an ordinary 
synchronous message, then this can be handled normally in 
the next block (fl) where the Kerberos Support Library 34 
notifies MARC 40 that the response is to be 
30 ~ synchronous'' . 

Then two operations are presented for execution 
at (fl) (Fig. 4) at this time. The system will let MARC 
know that it is waiting for response at (j), or otherwise 
at (g) the Kerberos server (or Kerberos Support Library) 
35 is going to go ahead and process this request. 
Alternately, there is the factor that this request can be 
serviced locally by KSL 34. This is shown in the block 
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at element (g) which indicates the statement that the 
Kerberos Server (20) or the KSL Library (34) is 
processing the reg:uest. This means that the service can 
be accomplished via the Kerberos Sexver 20 or locally on 
5 the Kerberos Support Library 34. In the event that it is 
on the Kerberos Server 20, the system will then receive a 
response back from the Kerberos Server and then the 
Kerberos Support Library will pass that response on to 
MARC at step (i) . This is shown at blocks (h) and (i) 

10 after which the response is sent to the marc program at 
the (j) block of Fig. 4. 

On this particular synchronous message path, it 
is expected that the response will occur within 
milliseconds. Thus, when MARC at position (k) returns 

15 the sezrvice requested, the client 10 will be informed and 
the program will stop at (L), in order to end the 
process . 

The term ^^service'' here means that a reczuest (a 
Kerberos command) has been made. This reczuest for 
20 sezrvice is the processing of the Kerberos command. An 
example of a service request would be: 

(a) Client wants to chemge his/her Kerberos 
password; 

(b) From MARC the client enters: 

25 KRB PASSWORD <old password> <new password> <new 

password> 

(c) Upon entering this command, the client 
workstation would receive the message as follows: 

Your KRB command is being processed. The 
30 response to this command will be placed in your 

system messages queue. You will be notified 
when your request has been serviced. 
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2Lfter an indeterminate period of time, the client 
workstation will receive a message: 

You have a message in your system messages 
Q[ueue. 

When the client examines his/her system messages 
queue, the following message (s) could be displayed. 

Your password has been successfully changed. 

or 

Your password has not been changed. <Error 
reason> 

Again referring to Fig. 4 and observing the 
decision tree at (e) where the block on the decision 

tree takes the ^^yes" path ^^Y" to indicate the 
^^asynchronous request.'' The *^yes" (Y) branch goes to 
block (f2) which indicates a separate process ^*C" which 
involves the processing of asynchronous messages and the 
handling of these messages. This involves a separate 
sequence (via process ^^C) which is shown in Figs. 6 
(A,B) and 7 (A,B) . 

Referring to Fig. 4 and proceeding from step 
(b) on the leg where the request is routed to the HCS 
(rather than to MARC) as indicated at block (c2) • This 
is a MCS (Message Control Management System program) for 
Kerberos service which then evolves to block designated 
(d2> which indicates a process ^^B" which is subsequently 
shown and discussed in Fig. 5. 

It may be noted that in Fig* 4, referring to 
the "synchronous" message passing branch ^^N" (No) at 
decision block (e), that the Kerberos Support Library 34 
notifies the system that the MARC response was to be 
"^synchronous" and then this is passed on to the Kerberos 
Server 20 at the Kerberos Support Library 34 which then 
receives the response. Then the Kerberos Support Library 
passes the response back to MARC at position (j) where 
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HARC was waiting for the response after which at step (k) 
the service re<zuested was returned by ISARC to the client 
10, so that at (L) the process came to a stop. 

The channel on Fig. 4 which goes from block 
5 location (b) over to block location {c2) involves an MCS- 
request for Kerberos service. This then involves the 
process block ^^B" which is designated at location (d2) 
and is discussed hereinafter in regard to Fig. 5 
(Process ^*B'0 . 

10 Fig. 5A will indicate a series of flowchart 

steps labeled Bl, B2...B6 which involved an earlier used 
sequence. At position Bl, the MCS request is generated 
and fed at B2 to the Kerberos Support Library 34 (Fig« 3) 
III which receives the request and calls the Kerberos Server 

15 20. Then at location B3, the Kerberos Server 20 will 
process the request and return it back to the Kerberos 
Support Library (KSIi 34) . 

At step B4, the Kerberos Support Library 
delivers the service request via directives over to the 
20 MCS where upon, at step B5, the COMS process 40 routes 
the message to the appropriate MCS. Thereafter at step 
B6, the MCS receives the requested service, at which time 
this process cycle is brought to an ending, after 
notifying client 10. 
25 The transition of the message (data) between B5 

and B6 is accon^lished via a queue. The Message Control 
Systems (MCS) will communicate outside their environment 
(stack) by using queues. In this instance, when the COMS 
program receives a message from the Kerberos Server 
30 Library 34, it forwards the message to the appropriate 
Message Control System (MCS) by placing the message into 
a queue array. Both the MCS and the COMS programs ^^knoW 
about the existence of the queue and operate to monitor 
it by means of what is called an ^^Evenf. The Message 
35 Control System (MCS) is waiting for an ^^Evenf to 
^happen*' which will then wake up the process MCS and will 
extract the information (data) which it now has a 
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visibility to. The ^Evenf handling, the moving of data 
from one environment to the other is controlled by the 
sacp 60. 

while the earlier provided systen^ shown in 
5 Fig. 5A required the time-constuning factor of calling the 
Kerberos Server which was then required to access the 
Kerberos Support Library after which the Kerberos Support 
Library had to respond, it will be seen that under the 
presently disclosed improved system, there is no longer 

10 any need for the doiible jump action of accessing both the 
Kerberos Server and the Kerberos Support Library since 
under the improved system, the Kerberos Support Library 
can provide an immediate synchronous response without the 
need to access the Kerberos Server 20. This will be seen 

15 in connection with Fig. 11 which is a simplified 
description of Fig. 1. 

As will be seen in Fig. 11, a series of 
principal modules 11, 12, and 13, are coimected to 
network cloud 16 to the Kerberos Server 20 which 

20 maintains a communication relationship on line 17 to the 
Control Capable Terminal (COT) . The difference between 
Fig. 11 and Fig. 1 is the addition of the Control Capable 
Terminal designed CI. A Control Capable Terminal (CI) is 
a terminal capable of entering secure administrative 

25 commands which are recognized by the Kerberos Server 20. 
The COT (CI) may be a physical unit attached to the 
Kerberos Server 20 via a local area network connection 17 
or could even be physically included within the Kerberos 
Server 20 such that the CCT would reside as 

30 administrative software in the Kerberos Server 20. 

Fig. 12 is a schematic view, specific to a 
particular simplified Kerberos realm designated 69 which 
uses the expedited synchronous message model. Here there 
are seen three basic constructs which may be considered 

35 as four constructs if the Control Capable Terminal, CCT 
(Cl) is included. These constructs process or manage the 
synchronous message within the Kerberos Realm 69. 
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It may be noted there may be additional 
principals 13 as seen in Fig. 12 and also clients 10 
within this realm or multiple realms. However, for this 
model there will be only one Kerberos Server 20 within 
5 any given particular realm. The following is a 
discussion of the processes involved in expediting 
synchronous message traffic over to a client 10. 

Referring to Fig. 12, there is seen a client 10 
connected to and from a network cloud 16 via the 
10 communication channel 15 while the network cloud 16 has 
communication channels 14 to the ClearPath NX Server 13 
and also via channel 18 to the Kerberos Server 20. The 
Kerberos Server 20 has a communication channel 17 to 01 
which is the Control Capable Terminal. Shown also in 
15 Fig. 12 is a series of independent or dependent processes 
or tasks which are designated with the letter P. The 
N process PI related to the Kerberos Server 20 is performed 

;L by the Kerberos Server 20 and is the initialization 

process of the Kerberos security mechanism resident on 
20 the Kerberos Server 20. This process PI processes the 
information stored in a file designated Fl which resides 
in memory on the Kerberos Server 20 or it may reside as a 
disk file which can be accessed by the Kerberos Server 
20. 

25 The file Fl contains various information about 

the specific Kerberos realm 69 involved for which it, 20, 
is the Kerberos Server. It may be stated for this 
discussion that there will no longer be any further 
mention of multiple Kerberos realms and/or slave Kerberos 
30 Servers which may possibly exist within any given realm. 
The described model will focus on a relationship of one 
server to one realm. 

Information in the configuration file Fl will 
contain information about its realm name, other realm 
35 names, and information about the principal (s) 13 which 
are within its sphere of control. Additional information 
about the clients 10, which also are often called 
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principals, is also found here. The process Pi of Fig. 
12 is completed after various initialization duties have 
been completed. At the c<»ftpletion of the process PI, the 
Kerberos Server 20 is now "^available'' for general 
5 processing of requests from any client 10 or any 
principal 13 or any realm. 

Process P2 of Fig. 12 is seen in the ClearPath 
Server at P2 and is the Kerberos initialization process 
for the ClearPath NX Server 13 which is also designated 
10 as a principal. The process P2 reads information stored 
in its configuration file F2. The information stored in 
this file F2 at initialization time is the realm name for 
which the principal 13 wishes to consider itself as 
belonging to that realm. D^on completion of the 
15 initialization process P2, the ClearPath NX Sezrver 13 
will now be able to process requests from other 
principals or clients 10 via the various network 
connections shown in Fig. 12 as 14, 15, 16, and 18. 

At any given time after completion of the 
20 process PI, then services may be requested of the 
Kerberos Server 20. In addition, changes may be 
requested by a client 10 or a principal 13 about its 
configuration or operational status. However, system 
wide changes or changes made by the administrator at the 
25 COT (01) for a particular client are stored in the file 
Fl in the Kerberos Server 20. 

The file F2 in the ClearPath NX Server 13 does 
not yet contain the ^^cheuige'' that already has been stored 
in the other file Fl. When a ^change'' occurs, a 
30 programmatic event changes the state on the Kerberos 
Server 20. This change is also noted on the ClearPath NX 
Server 13 via the conmiunication links 18, 16 and 14 and 
the process P5 is then initiated by the ClearPath NX 
Server 13. This process request will execute data 
35 transfers so that any change made to the file Fl (in 
Kerberos Server 20) will be forwarded to the ClearPath NX 
Server 13 and then recorded in the file F2 of the 
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principal 13. The files Fl and F2 are called 
^^Configuration Files" and contain the name of the 
Kerberos realm plus the names and attributes of the 
principals participating in that realm. The Kerberos 
Security Administrative Commands are a method of 
req^iesting information from the configuration file, about 
the principals and the attributes associated with each 
principal • 

Kerberos Server 20 initiates the process P6, 
forwarding the updated data to the ClearPath NX Server 
13* This process or processes are repeated as necessary 
to keep the files Fl and F2 in a synchronous state. 

The client 10 makes requests for service 
related specifically to itself as client 10. Here it is 
assumed, at this point, that the client 10 has been 
authenticated and has or has been actively participating 
with the Kerberos realm 69 as administered 1:^ the 
Kerberos Server 20. A request for service by the client 
10 is passed by some combination of network communication 
links such as 14, 15, 16, etc. through the ClearPath NX 
Server 13. Since the ClearPath NX Server 13 had been 
previously been ^^updated'' about any changes via the 
process P6 of Fig. 12 by the Kerberos Server 20, the 
ClearPath NX Server 13 can directly respond in a 
synchronous manner (in behalf of the Kerberos Server 20) 
back to the client 10 via the communication links 14, 16 
and 15. 
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Now as a result, prior to the improved 
ea^pedited message control system, the earlier system 
would operate such that a request for service was made by 
the client 10. This request would then be forwarded to 
5 the ClearPath NX Server 13 via the communication links 
15, 16 and 14. Then the ClearPath NX Server 13 would 
query the Kerberos Server 20 via the process P3 each time 
that a request for service was initiated by a client 10 . 
Then the Kerberos Server 20 would respond to this request 

10 (P3) via the process P4 returning the response to the 
ClearPath NX Server 13 on behalf of the client 10. Then 
in turn the ClearPath NX Server 13 would retuam the 
requested information via the communication links 14, 16 
smd 15 • Unfortunately, this method was rather time 

15 consuming with considerably delays which could be 
expected since very often the Kerberos Server 20 was 
under a heavy load* In addition to the communication 
links and protocols used to transport data via the 
process P4 using the links 18, 16 and 14, these links 

20 were relatively slow and required additional overhead 
during many time-critical requests. 

As a result, the improved expedited system as 
seen in Fig. 12 operated in a much more expeditious 
fashion. Here, the client 10 makes a request for service 

25 related specifically to itself as client 10. Of course, 
it is assumed at this point that the client 10 has been 
authenticated and is or has been actively participating 
within the Kerberos realm 69 as administered by the 
Kerberos Server 20. A request for service by the client 

30 10 is then passed by a combination of network 
communication links such as 15, 16 and 14 over to the 
ClearPath NX Server 13. Since the ClearPath NX Server 13 
had been previously ^^updated" about any changes via the 
combination of the process P5 and P6 by the Kerberos 

35 Server 20, now the ClearPath NX Server can directly 
respond to the client 10 in a synchronous manner on 
behalf of the Kerberos Server using the communication 
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links 14, 16 and 15. Thus this avoided the variable 
delays associated imder the earlier system which required 
cosununication links 18, 16 and 14. 

Fig. 9 (9A, 9B, 9C) indicates word formats on 
5 the ClearPath NX Server and shows the MARC message 
layout, the MCS message layout, and the message display 
format. A word consists of forty-eight data bits and 
three leading control bits which define the type of word. 
The control bits for words shown in Fig. 13 are all zero; 
10 making the control value zero. Fig. 14 is a conceptual 
diagram of a word array that is passed from process to 
P process. The words as marked in Fig. 9 are represented 

by Fig. 13 and can be referenced as such. The passing of 
messages asynchronously uses a message array containing a 
15 header and message data. In this particular instance the 
data is being passed from the Kerberos Support Library, 
KSIi, Fig. 3 (34) to HARC, Fig. 3 (40). 

The details associated with Figs. 13 and 14 is 
as follows: 

20 Words zero through five are control words 

(information) for KSL to communicate and route a message 
to/ from COHS. Words six and up contain control and text 
data which is interpreted by MCS(s), such as MARC, which 
will in turn ultimately route the message to the 
25 appropriate client. 

MSGEO] The boldface item numbers (#) below refer to 
the encircled item ntombers in Fig. 13. 

#1 [47:08] :s 13 % tells COJllS to route message to MARC 
#2 [39:08] :» 1 % tells COMS incoming message from KSL 
30 [31:32] :» 0 % NOT USED FOR THIS IMPLEMENTATION 

#8 MS6[1] - MS6E5] 

COMS CONTROL HEADER - NOT USED FOR THIS 
IMPLEMENTATION 



m 



pi: 
;»!!' ; 

m 
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NOTE: MSG[0] through MSG [5] are used by CC^S and will be 
removed before delivery to any MCS. 

MSG [6] 

[47:08] 1^0 % MOT USED FOR THIS IMPLEMENTATION 

5 #3 [39:08] :» X % tells COMS incoming message from KSL 

[31:32] :s 0 % NOT USED FOR THIS IMPLEMENTATION 

#7 [15:16] := <description> ; % Error #, ID expiration 

MSG [8] 

For MCS{s) other than MARC 
10 [47:48] := <identity word #2> 

for MARC 

Not used. 

MSG[9] - MSG [10] 

For all MCS(s) and MARC specifically related to log- 
15 on axid KRB INIT 

#9 Credential Handle. 

For all MCS(s) and MARC specifically related to log- 
on and KRB INIT 

Not used. 

20 MSG[11] - MSG[12] 

Reserved for future use. 

MSG [13] 

For all MCS(s) and MARC 

< start of text ]iiessage> 

25 NOTE: The highlighted numbers listed above, for example, 
#10, correspond to the circled number in Fig. 14. 
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The values for X in field [39:08] are as 



follows: 



13: An asynchronous message from KSIi (not 
Controller) ; identifies a message related to the KRB 
5 INIT command or non pre-authenticated logon 

indicating the request was successful. 

15: An asynchronous message from KSL (not 
Controller) ; identifies a message in which an error 
occurred during the processing of the KRB INIT 
10 command or non pre-authenticated logon. 

16: an asynchronous message from KSL (not 
Controller)/ identifies the message as a response to 
any KRB command other than KRB INIT. The response 
returned indicates a successful inquiry. 

15 22: An asynchronous message from KSL (not 

Controller) ; identifies a message in which an error 
occurred during the processing of a KRB coxmaand 
OTHER THAN KRB INIT. 

#4 [7:8] := <text length (characters>; % Message length 

20 MSG [7] 

For MCS(s) other than MARC 

[47:48] := <identity word #1> 

For MARC 

#5 [46:15] := <tr€ms„id>/ % Transaction identity 

25 #6 [31:16] := <dialog #>; % Dialog number 



Fig. 15 depicts a process flow diagram of the 
independent and dependent process associated with an 
expedited synclironous message control model. 
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In Fig. 16, which is an exploded view of both 
the ClearPath NX Server 13 and the Kerberos Server 20 
from Fig. 12, it should be asstuned that the communication 
channel (s) 14 and 18 (Fig. 12) ultimately are connected 
via a LAN (Local Area Network) and/or a WAN (Wide Area 
Network) connection with facilitates communication 
between these two principals (servers) within the 
Kerberos realm. 

During the initialization phase of the Kerberos 
Server 20, an independent process Pi is responsible for 
obtaining information stored in file Fl (Fig. 12) which 
is either stored on a disk either locally or as a file 
which the Kerberos Server disk either locally or as a 
file which the Kerberos Server has visibility to, via a 
network. The process Pi initiates a read RIA which 
obtains realm for which the Kerberos Server 20 
administers. The information is returned from file Fl 
via read result RlB to process PI which builds any 
internal structure (s) necessary to administer the 
Kerberos realm. At this time the Kerberos Server 20 is 
now available" to process any request from any principal 
or any other realm. 

Independent of process PI (Fig. 12) on the 
Kerberos Server 20, process P2 (in Server 13) is the 
initialization process of the Kerberos Support Library 40 
(Fig. 12) resident on the ClearPath NX Server 13. 
Process P2 functions in a similar method to that of 
process PI. Process P2 executes a read R2A on the file 
F2. The read result R2B from file F2 returns information 
about any principal (s) it had been previously been made 
aware of, along with the ^^name'' of the realm for which it 
is a member and any other configuration information. 
Once process P2 has completed the read operation it 
processes off to a dependent task P3 . Process P3 
initiates an update request for realm and principal 
information. This request is a call C3 to the Kerberos 
Server 20. Process P4 which, if not already initiated, 
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is processed off. The incoming call 04 indicates to 
process P4 that an update is being requested. Process P4 
executes a read R4B of file Fl« The read result R4A is 
returned to process P4. Process P4 packages the 
5 information using a shared mutually agreed-upon protocol 
and initiates a return C4 back to process P3 which has 
been waiting. Process P3 executes a Write R3 to file F2. 
Upon completion of this task, process P3 notifies process 
P2 of the success or failure in obtaining current 

10 information from the Kerberos Server 20. Process P3 now 
terminates regardless of the outcome of the update. If 
the update process P3 returned a result indicating 
failure, process P2 waits a predetermined period of time. 
After that time period has eiQ>ired the above process P3 

15 is repeated. This continues until process P2 obtains a 
successful result and is made '^available'^ to perform 
Kerberos -related fiznctions. If the information was 
successfully returned, process P2 finishes its 
initialization by making the ClearPath NX Server 13 

20 ^^available" to any principal requiring service. At this 
point in time both files Fl and F2 on the Kerberos Server 
20 and the ClearPath NX Server 13 share in a state of 
S3n^chronicity . 

Once files Fl and F2 have been synchronized, 

25 any requests received by the ClearPath Server 13 can be 
responded to directly. in the event that a change has 
occurred on the Kerberos Server 20, the change is noted 
and file Fl is updated. A corresponding change is noted 
and file Fl is updated. A corresponding change is 

30 necessary on the ClearPath NX Server 13. To accon«)lish 
this ^^update'' the Kerberos Server 20 initiates the 
process P5. Process P5 processes changes received by the 
Kerberos Server 20. As part of the update process, 
process P5 initiates call OS to the ClearPath NX Server 

35 13. The ClearPath NX Server 13 initiates process P6 
which in turn performs a ^^Write" operation R6 which 
updates file F2. Once again at this point files Fl and 
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F2 are again synchronized. Process P7 handles requests 
made via communication line 14i, (Fig. 12). Vlhen a 
service is requested, the Kerberos Support Library 40 
initiates process P7. Process P7 starts a Read R7A from 
5 file P2. The Read result R7B returns the requested 
information. Process P7 is then able to return a message 
in response to the clients' request via communications 
line 14o. The time-saving shown here is that process P7 
has a single read/process to return the result to the 

10 client. Without initial and event-driven updates, the 
processes P3, P5, P6 would have to be performed while the 
client waited. This is no longer the case, and a fast 
immediate response can now be effectuated to provide the 
appropriate response to the client. 

15 Fig. 6 is a flowchart comprising Figs. 6A and 

6B illustrating the steps involved in the hemdling of an 
"^asynchronous service'' request from the KUkRC processes 
40. This block involves the ^^C" block which was 
indicated in Pig. 4, at position (f2). 

20 Operational Prpcegs^g for Block Process ^^C» (Fias. 

6A, 6B) Asynchronous Service Request from fSARd 

(1) A User-operator residing at a client work 
station 10 requests a service via a Kerberos command 
using the MARC processes, (a, b, cl, dl, e, f2, of 

25 Fig. 4). 

(2) ^is request is processed at the client work 
station 10. 

(3) The client work station 10 forwards this 
request to the appropriate Unisys ClearPath NX 

30 Server 13 (Figs. 2,3) via the client's functional 

transport mechanic. For example, this might be Net 
BIOS over the IPX or over the HLCN, the Telnet or 
Station Transfer Unit, etc. of Fig. 3. 
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(4) Regardless of which one of these transport 
mechanisms is used, the reciuest is received by the 
imisys NX Server 13 and all the network processing 
will occur such that the service request is received 

5 at the appropriate networking host software level 

via elements 46, 48, 50, Fig. 2, whose software 
functions to communicate with PC based tezrminal 
emulators • 

(5) The networking host software passes this 
req^est to the CODfS 42 for distribution (at position 
b of Fig. 4)« Networking software (46, 48, 50, 52) 
on the NX Server 13 takes the message and constructs 
additional levels of protocol such as transport, 
session, and networking used to route messages on a 
network • 

(6) COMS upon receiving this request (b), (Fig. 4) 
validates that the MCS request is valid. In this 
particular case, this particular request is to be 
processed by MARC 40, via (cl) (Fig. 4). As such 
the ca&SS(b) will strip header information intended 
for its use and then add header information intended 
to direct a request to MARC 40 (cl) and the 
information to help MARC with the internal 
processing. 

25 (7) MARC 40 receives the service request and notes 

that the request is a Kerberos coxmnand (cl. Fig. 4). 
The processing of Kerberos commands is handled 
outside of the MARC environment via the directives 
portion of the Kerberos Support Library (KSL) 34 

30 (Pig. 2). 

(8) MARC 40 then calling the directive's interface, 
passes the Kerberos command to the Kerberos Support 
Library 34, Fig. 3 (KSL) for processing. 
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(9) The KSL 34 receives the request (dl, Fig« 4) to 
process the Kerberos command. This will be seen to 
correlate to step (i) of Fig. 6A) . 

(10) The Kerberos Server Support Library 34 scans 
5 the Kerberos coimnand to determine if the response to 

the command is to be returned synchronously or 
asynchronously (position (e) of Fig. 4A.) , to the 
original requester which correlates to step (ii) of 
Fig. 6A. 

10 The assumption will now be made that all 

further operations will refer to ^^asynchronous" 
responses . 

(11) The Kerberos Support Library 34 determines 
that the response is to be as3rnchronous (Ysyes) . At 

15 this stage, the KSL 34 must obtain additional 

information from the immediate requester (XOARC 40) 
about the originator. The KSL must also infoxm MARC 
the response will be returned asynchronously. 
Fig. 4 indicates the block ^^C" at position (f2) 

20 which indicates the subsequent sequences which will 

be described in Figs. 6A, 6B and 7 A, 7B. The 
following steps 12 through 34 provide an initial 
generalized sxumary of these actions. 

(12) The Kerberos Support Library 34 requests the 
25 client-originator information and builds a request 

to be sent to the Kerberos Server 20. In addition, 
it builds a message (in clear text form for display) 
which message can be used or discarded by the 
originator. The message states that the response to 
30 the Kerberos command which was entered will be 

returned ^asynchronously'' as an unsolicited message. 

(13) MARC 40, having been notified that the 
response to its request will be returned 
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asynchronously/ notes the dialog ntmiber of the 
specific User who has entered the Kerberos COTimand. 

(14) MARC assigns a «TRANSACTION_ID" (transaction 
number) for this recjuest and then stores this along 

5 with the MhRC dialog nxunber. 

(15) MARC, ignoring now the KSL-generated clear 
text message, then builds a message for the 
originator and sends the message. 

(16) MARC releases the session (iii of Fig. 6A) 
CI 10 which has been waiting for a response. As a result, 

the originator is now free to perform other tasks 
(v of rig. 6A) . 

(17) MARC forwards the TRANSACTION_ID over to the 
KSL 34 (Kerberos Support Library) which has been 

; 15 waiting for this information. 

(18) The Kerberos Support Library (KSL 34) sends a 
request to the Kerberos Server 20 requesting service 
by performing a Write request over to the XJDP port 
26 (Pig. 2) (vii of Fig 6A) . 

20 (19) The Kerberos Server 20 detects activity in the 

UDP port 26 and then Reads the request. 

(20) The Kerberos Server 20 then performs the 
service. After an indeterminate amount of time, the 
Kerberos Server 20 with the response formatted, 

25 writes to the UDP port 15 of the ClearPath NX Server 

(Fig. 2) which is then detected by the KSL 34. 

(21) The Kerberos Support Library (KSL 34) performs 
a Read on the UDP port 15 and obtains a response. 

(22) The KSL 34 matches control information 
30 returned by the Kerberos Server 20 and builds a 
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response constructing em appropriate header, 
together with the stored TRANSACTION.ZD. 

(23) The KSL 34 calls an ejcport procedure in the 
master control program (MCP internal provider 33^ 
5 Fig« 2) which then delivers a message from the KSL 

34 to COMS 42 via an intercom queue. This intercom 
queue is located in Fig. 3 within the queue 
management ftmction block 62. Its function and 
layout is further shown in Fig. 10. 

10 (24) The master control program MCP 60 Fig. 3, 

causes an event which is monitored by MARC (with 
COMS as an inteormediary) for its intercom queue and 
then inserts the response. 

(25) This response is passed from the MCP 60 over 
15 to COMS 42 on behalf of MARC 40, Fig. 3. 

(26) COMS transforms this response into a message 
format that MARC 40 can now decode. 

(27) MARC detects an "event" has been caused which 
notifies it that an "^"unsolicited message'' has 

20 arrived. 

(28) MARC 40 examines the message and notes that 
the message, that has arrived, is a message response 
to a Kerberos command. 

(29) IHARC prepares to deliver the message by 
25 matching the TRANSACTI0N_ID over to a MARC Dialog 

Number. if the Dialog Number is still active and 
had previously initiated a Kerberos COTimand, MARC 
puts the message in a displayable format for 
delivery. However if the Dialog Number is no longer 
30 active, the message is then discarded. 

(30) MARC 40 then passes the message over to COMS 
42 for actual delivery. 
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(31) COMS passes the messages to the networking 
software on the MX Server 13 • 

(32) The networking software on the NX Server then 
constructs a message using the appropriate transport 

5 protocol mechanism, such as Net BIOS, TCP/IP, and so 

on for transport to client 10. 

(33) The incoming message is then processed on the 
client workstation 10. 

10 (34) The User-operator sitting at the client 

workstation 10 is then notified that a message has 
arrived for his or her review. 

Figs. 6A and 6B show flow chart diagrams 
illustrating the operational steps of the processes 
15 involved in the location (f2) designated block ^^C" of 
Fig. 4. As seen in Fig. 6A, the Kerberos Support Library 
receives a request for service (i) . Then the Kerberos 
Support Library notifies the Menu-Assisted Resource 
Control Program (MARC) that an ^asynchronous'' service is 
20 recruested (ii) . At branch 61, (Fig. 6A and 7A) the MARC 
process notes the details of the client and ''^releases,'' 
at step (iii), the session. The '^session'^ is used to 
denote the active connection between a User and a 
computer or between two computers. This provides an 
25 input back to the original re<iuester 10 which then leaves 
the client free to initiate a new service re<iuest, step 
(v), thus to continue with further operations even though 
the service for the original reg[uest was not yet provided 
by the Kerberos Server 20. 

Returning now to the Fig. 6A block designated 
(ii) where the KSL 34 notifies MARC 40 that an 
asynchronous service is reqcuested. Now, the process 
cycle 62 (Figs. 7A, 7B) occurs over at location step 
(vii). Fig. 6A, where the Kerberos Support Library builds 
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a service request and stores the "^client Information". 
This then proceeds to location (viii) Fig. SK at which 
the Kerberos Server 20 processes the service request. 
Then, at location (ix), here, the NX server 13 receives 
5 the asynchronous response after which at location (x) the 
Kerberos Support Library receives the message. An 
auxiliary operation can occur at location (x) where the 
path 63 indicates that the Kerberos Support Library then 
builds a message header at location (xii) • 
10 Then, at position (x), the Kerberos Support 

Library having received the message continues on to 
position (xi) designated as ^^P'' which continues as shown 
in Fig. 6B. 

At position (xi) designated ^P'' of Fig. 6B, it 

15 is then necessary to refer to Fig. 7B which shows the 
Queue Insertion Event (at xisp) , Then, as shown in Fig. 
63 at position (xiii), the Kerberos Support Library 
inserts a foannatted message in the queue. The Kerberos 
Support Library 34 has built the message, that was 

20 received from the Kerberos Server, and placed into a 
queue array, plus attaching in certain control 
information. The Kerberos Support Library (KSL) then 
"^inserts" this message using an '^'insert construct^"^ as 
provided by the DCAL(30L programming language. vthen the 

25 ^^insert statement is executed, then the MCP code will 
then be invoked. 

Now referring to Fig. 6B, the process ^^P'' 
continues at position (xi) over to the position (xiii) 
wherein the Kerberos Support Library inserts a formatted 

30 message in the queue (62, Fig. 3) and detailed in 
Fig. 10. Then, at position (xiv), the master control 
program (MCP) notes the queue event and passes the 
information onto COHS. In summary, and as a continuation 
from position (xi), the MCP code is invoked on top of the 

35 queue stack environment (at P of Fig. 7B) which will then 
process the ^^insert event statement''. This code then 
takes the array (a structure containing the data or 
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message), which is actually a data descriptor, and in 
combination, noting the source and the destination, then 
lays the groxmdwork to ^notify" the destination. The 
COSSS program is the interim destination. The Master 
5 Control Program ^causes" an Event which the COMS 
environment has been monitoring. When this Event 
^^happens", the COMS program now has visibility to the 
array (data descriptor) , which will then be routed by 
another gueue over to the MARC program, via 61 of Fig. 7B 

10 over to 61 of Fig. 7A. Thus it can be said that the MARC 
program receives the message at position (xvi). Fig. 6B. 

This processing function then proceeds to 
position (xv) where COMS then notes the queue event and 
passes the message on to MARC. Then at position (xvi), 

15 the MARC process receives the imsolicited message in the 
control <xueue Fig. 10. At position (icvi), it is seen that 
the MARC program receives the xinsolicited message in a 
q[ueue. 

An ^^Unsolicited Message'' is a message generated 

20 by any software which will be ultimately displayed by 
another software which is not in a ^^wait" state (waiting) 
for said message to be delivered to it. The receiving 
software is not aware (programatically) that a message is 
being delivered. Conversely, a "^Solicited Message^ is a 

25 message generated by any software for which another 
software is waiting (the process environment is 
suspended) and the receiving software is aware that it 
will be receiving this message. 

The process of ^receives" is an instance again 

30 of moving data from one environment to another 
environment using a queue. The data descriptor which 
points to the data in an area of memory is passed from 
one process to a different process. The MARC program 
receives the MSG (data descriptor) from COMS, and then 

35 MARC will then process this message (xxi) which will 
ultimately be passed back to COMS for delivery shown at 
position (xxii). At position (xxii), it is seen that COMS 
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receives the message to be delivered to the original 
requester. Here, COMS receives the message from KUAC. 
Then through a series of procedure calls, the message is 
eventually delivered to the appropriate transport for 
5 delivery at the original client-requester 10, 

Then, along the communication channel 64 
(Fig. 6B) to the position (acvii), here the MARC program 
processes the unsolicited message and also checks the 
present validity of the original request. 

10 Thus, at position step (xviii), MARC verifies 

to see whether the original requester is still a valid 
requester, after which at position (xix), a check is made 
at the decision tree to determine whether the particular 
station is still valid. If the station is valid, Y = Yes, 

15 then at position (xx) a "^valid return'' signal is sent, 
location step (xvi), where MARC receives the unsolicited 
message in a control queue, at which time on channel 65, 
at position step (xxi), MARC converts the encoded station 
information into a COMS message format. This is sent via 

20 position (xxii) whereby COMS receives the message to be 
delivered to the original requester at the terminal 10. 

Figs. 7A and 7B are a set of drawings showing 
the stack of processes used in a sequential set of 
software operations. In Fig. 7A, the left-hand stack 

25 designated ^^lOOs" is marked as the NX/TCP/MARC stack 
capsulate. The stack ^^2 00s" on the right side of Fig. 7A 
is designated as the Kerberos Support Library stack 
capsulete. Sequential interconnections between stacks 
100s and 200s are shown. 

30 In Fig. 7B, the process stack designated NX MOP 

environment is the sequence of processes which originate 
from the pointer p, location step (xi) coming from 
Fig. 7A. 

The lower portion of Fig. 7B is the processor 
35 stack environment for the Kerberos server correlating the 
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pointer PI location step (xi-1) of Fig. 7A and also the 
pointer P2 location (xi-2) coming from Fig. 7A. 

Referring to Fig. 7 A, the stack capsulete 100 
starts with the Kerberized client request received by the 
5 NX searver 13. Then the transmission control 

protocol /internet protocol provides communication to the 
COMS software whereinafter the COMS routes the request to 
MARC for processing Support Library to process the 
command. Then^ a call is made to the Kerberos Support 

10 Library to process the command^ after which there is a 
period for awaiting the return aaod a call-back. The call 
back process is the KSL informing MARC that this caaamand 
will be processed asynchronously. In addition KSL 
requests several attributes (the MCS number and 

15 Transact ion^XD) such that KSL may return this infoinooation 
for routing purposes to MARC when the final response is 
returned. 

Since MARC can receive Unsolicited Message (s) 
from other software's like Controller, it is intended to 

20 show that the message MARC received is a message from 
KSL 34. There is a fine distinction between box (xvi) 
and (xvii) in Fig. 6B; in (xvi) MARC is receiving an 
unsolicited message from someone. in (xvii) MARC now 
knows it to be a Kerberos message from KSL 34. 

25 The M2^C program notes the station information 

and stores the information (Stack 100s, Fig. 7A) • The 
MARC program notifies the requester and ^^releases" the 
station for other operations. 

Mow MARC maps the dialogue number to the 

30 Transact ion_lD and returns the dialogue number to the 
Kerberos Support Library. This brings the process to (61) 
shown in stack 100s which correlates to Fig. 6A 
designated (61) between the step (ii) and step (iii) . 

Note that in stack 100s (Fig. 7A) , there were 

35 several intermediate steps, such that the step involving 
"^Calls Kerberos Support Libraxry To Process Command'', will 
be seen to communicate to the stack 200s whereupon there 
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is a processing of the Kerberos command and the building 
of a requester message after which there is a 
notification to MARC via a "^call back'' procedure, such 
that the response to the Kerberos command is to be 
5 returned ^^asynchronously". This is then fed over to the 
first stack 100s at the block designated ^^Await Return 
And Call-Back''. S\ibseq[uently at stack 100s at the 
function where MARC maps the dialogue number to the 
Transact ion_ID and returns this data to the Kerberos 
10 Server Library, there is then a sequence over to the 
stack 200s (Fig, 7A) where the system stores the 
r| TransactionLjCD and associates it with a pending request 

to the Kerberos server, after which the system builds a 
;|j header and request message which then involves a request 

15 of service via the User Datagram Port (UDP) to the KDC 
(Key Distribution Center) 22, Fig. 2. 

The request for service via the UDP to the KDC 
in stack 200s is seen at location (xi-2) ^^P2'' which is 
further continued on Fig. 7B where the Kerberos server 
20 receives the request via the UDP port then processes the 
request and builds the response, then sends out the 
response via the UDP port to the NX server 13 which 
f\mction is continued as «P1'' which relates back to 
Fig. 7 A at location (xi-1) . 
25 Here, at Fig. 7A, step (xi-l)=Pl, there is a 

KDC event, such that the message is processed to send 
back to the originator. Then proceeding upward in stack 
200, the Kerberos Support Library will build the message 
header with a Transaction_lD match after which there will 
30 be an insertion of the message in the queue for delivery 
to the requester at location (xi) ^^P"* Now referring to 
Fig 7B, the NX_MCP environment shows the sequence at *^P'' 
(xi) which involves a queue insertion event, followed by 
an action to validate that the queue is active euid to 
35 cause an ^evenf for monitoring the process. 

Then, a call is made to (61) located on stack 
100 (Fig. 7A) followed by the events shown on the upper 
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part of stack 100s, where the COMS-event has ^^happened" 
and notes a message for M&RC. Then, the message is 
passed to lUKRC with the appropriate header, after which 
SSJkRC receives the unsolicited message* At this time, 
5 there is also a validation cycle to validate that the 
client is still valid. After this, MARC recalls the 
client dialogue number and if valid, forwards the 
dialogue nxzmber. If the dialogue number is invalid, then 
MARC will discard the message. This is followed by a 

10 call to position (62) of Fig. 7B whereby the client- 
server 13 is seen to transport the response to the client 

with a message as "^your password has been 

successfully changed'^. 

Thus, in summary, the asi^nchronous service 

15 request from MARC designated as ^^process C is seen in 
Fig. 6A so that now referring to Fig. 4, the client 
service request is being routed to the MARC whereby MARC 
requests for Kerberos service and the Kerberos Support 
Library receives the request for service (dl. Fig. 4), 

20 will then select the ^^asynchronous" message choice at (e) 
which will then trigger the process ^X", location {f2) 
which is then instituted at Fig. 6A, together with 
Fig . 6B • 

In Fig. 6A, a series of processes designated 
25 (61) operates between the moment that the Kerberos 
Support Library notifies MARC that an asynchronous 
service is requested and at the point (iii). Fig. 6A, 
where the MARC program notes the client's details and 
releases the session back to the original requester at 
30 terminal 10, after which the client is free to initiate a 
new service request even though the asynchronous service 
request has not yet been consummated. 

However, subsequently, an unsolicited message 
will be generated by the Kerberos server and the MARC 
35 program in order to notify the client via an unsolicited 
message that he may proceed with his original request, 
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since he has now been authenticated by the Kerberos 
Server. 

Thus, the User-client can initiate a first or 
original reqcuest for service in a Kerberized environment 
5 and does not have to wait for a validation and completion 
of that original request before he can proceed to do 
other reqruest operations. After receipt of an 

unsolicited response to this original request, the 
originating client-User operator can then pursue the 
10 original request. 

Figs. 8 and 9 were previously described under 
the heading of ^GENERAL overview. 
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DESCRIPTION OF PREFERRED EMBODIMENT; 

The present system provides the service of 
client authentication in a Kerberos Domain or Realm 
5 through use of an asynchronous message process where the 
clients are authenticated partially by a softvrare process 
residing in the client-server module. Referring to 
Fig* 15, there is seen a diagram showing the major 
operating elements which provide for a client 

10 authentication and validation of communications which are 
funneled through system libraries which provide several 
software processes. The client-server 13 in Fig. 16 is 
shown to be connected to the client terminal 10 which 
communicates commands to the client-server 13 and 

15 receives back certain responses. The client server here, 
designated the '^'ClearPath NX" server, is provided with 
the Master Control Program module 60, which interacts 
with the Menu-Assisted Resource Control Program 40. The 
Menu-Assisted Resource Control Program 40 (MARC) 

20 communicates with the COMS 42 (Communications Management 
System) which then interacts with the Kerberos Support 
Library 34. The Kerberos Support Library 34 then 
communicates with the Generic Security Service - 
Application Program Interface 38 (GSS-API) for the 

25 purpose of accessing security services. 

The Encryption Library 32 communicates with the 
Kerberos Support Library 34 and the Generic Security 
Service module 38. 

The client server 13 operates within a Kerberos 

30 domain which is provided by the Kerberos Server 20 having 
a key distribution center 22, and a Kerberos 
administrator program 24. 

Fig. 16 provides an overview of the operating 
modules which provide client authentication using the 

35 asynchronous message module. 

As seen in Fig. 16, the ClearPath NX Server 13 
has communication lines to the client 10 and also to a 
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coomnnmications lines to the Kerberos Server 20. within 
the ClearPath Server 13, there is indicated the COHS 
program 42 which works in communication with JSKRC 40 and 
also with the Kerberos Support Library 34. The Ed&RC 
5 program 40 communicates with the Master Control Program 
(MCP) 60 which also has communication lines to the 
Encryption Library 32* The Kerberos Support Library 34 
is coimected with coxmnunication lines to the general 
security services application program interface 38* 
10 The Kerberos Server 20 is then seen to have its 

internal modules involving the Kerberos Administrator 24 
Q and the Key Distribution Center (KDC) 22. 

Fig. 17 is a generalized drawing which shows 
another expanded view of the system wherein the client 10 
15 communicates through a network cloud 16 which connects 
the client to the Kerberos Server 20 and to the client 
server unit 13. 

Then the client server 13 is seen to have the 
intercoimecting modules indicated whereby the User Data 
20 File 36 is connected to the Menu*Assisted Resource 
Control Program, MARC 40. The MARC 40 is seen connected 
to the COMS program 42 and additionally has communication 
lines to the Kerberos Support Library 34 and the GSS-API 
Library 38. The Kerberos Support Library 34 has 
25 cozmections to a Digest Support Unit 73 and also coxmects 
to the Master Control Program 60 which coordinates with 
the COMS program 42 and the MARC program 40, and uses the 
Log File 72 to store the accumulated data. 

Now referring to Pig. 18, there is indicated a 
30 ^^process diagram'' which shows the operative elements 
involved together with a series of numerical indicators 
designated li, 2i, 3i, . . . up to 58i. These ^^i'' numbers 
provide a se<iuence of software steps and operations which 
provides the software mechanism for authenticating a 
35 client or principal in the Kerberos domain through 
utilization of an asynchronous message process when the 
client has not previously been pre-authenticated. 
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The major elements seen in Fig. 18 are shown as 
the client personal conqputer 10, which is interconnected 
to the ClearPath NX server 13. Within the ClearPath NX, 
server 13, the operating elements are seen to be the 
Communications Management System, COISS 42, which 
communicates with the Menu-Assisted Resource Control 
Program 40. These two modules are controlled and 

communicate with the Master Control Program 60 (MCP) 
which has a connection to a Log file 36 and a User Data 
file 72. 

The Master Control Program 60 is seen 
interconnected to the General Security Services unit 38 
which also interconnects to MARC 40 and to the Kerberos 
Support Library 34. The Kerberos Support Library 34 
(also indicated in Fig. 2) is seen connected to the 
Kerberos Server 20 which has a Key Distribution Center 22 
(KDC) • Additionally, the MARC 40 program also 

interconnects to the Kerberos Support Library 34 (KSL) . 

Now referring in Fig. 18 to the sequence of 
software operational steps which are involved in 
authenticating the client or principal in the Kerberos 
domain with an asynchronous message process, there is 
5 seen a series of sequential numbers designated li, 2i, 
3i, . . . up to 58i, which will be described herein in a 
sequential set of functional steps. 

At step li, the User Client 10 enters Logon 
information on the Kerberos Logon screen and initiates 
10 the tranffliit operation. This message is transported by 
any ntamber of network protocols and is not specific to 
any particular protocol. At step 2i, the Logon 
information is transported from the client 10 over to the 
Menu- Assisted Resource Control Program 40 (MARC) . 
15 At step 3i at the MARC program, the MARC 

program 40 performs security checks, for example, in 
order to verify the password entered in a protected 
field, and places a string on the front of the package 
that will be sent to the KSL 34. The string includes: 
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the text ^^INIT"; the <Principal ID> and <Password> 
entered by the user in step 11 (e.g«, '^ZNXT<Principal ID> 
<Password> • INIT allows a User to logon to the Kerberos 
Server 20 to obtain credentials as a Ticket Granting 
5 Ticket (TGT) and a session key. 

At step 41, MARC 40 will send this package over 
to the Kerberos Support Library 34 (KSL) • Here, at step 
51, the Kerberos Support Library performs a syntax 
checking on the package received. 

10 The INIT token as the first of the message, 

will be followed by two or three additional tokens a 

Principal^lD axid a password or Principal_Name, which is 
optionally followed by a Realm^ifilame, and a password. The 
KSL verifies that the Principal_ID (or Principal.Name and 

15 optional Realm^Name) obey the standard syntax rules. 

At step 61, the Kerberos Support Library, KSL 
34, creates a new KSL-credential- structure to hold 
Information pertaining to this particular client (e.g. 
PID and password) . KSL then builds an Authentication 

20 request (AS_Req message). The KSL 34 allocates a new 
KSL-credential-structure from a pool of such structures 
and stores the Principal_lD in it. The logon data is 
then converted to the user's secret key which is saved in 
the structure. KSL 34 then builds a AS_Req message, the 

25 format of which is described in RFC 1510, Section 5.4.1. 
"KRB^KDC^REQ Definition", and stores information relative 
to the request in an AS-Req-stxructure, also obtained from 
a pool of such stxructures. This information includes the 
KSL-cred-handle which identifies the KSL-credential- 

30 structure and a random niunber (called the ^^NONCE") which 
is also contained in the AS_Req message. 

At step 71, the Kerberos Support Library 34 
sends the AS_Req message over to the Key Distribution 
Center 22. The UDP protocol is used to send the message 

35 to Port 88 at the IP address indicated for the KDC 22 
SBTv^lng the realm indicated by the entered Principal_ID 
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(if no realm was provided, the configured local realm is 
assumed) • 

At step 8i, the KSL creates a ^^processing 
requesf message for the MARC program 40. This message 
5 is contained in an ^^OXJTPUT MESSAGE ARRAY" which allows 
translation of the message to any text in any natural 
language. The KSL 34 merely calls a standard procedure 
which copies a message to a buffer ready for passing to 
MARC 40. 

10 Then at step 9i, the KSL passes a ^^Processing 

request'^' message over to MARC 40 via the ^^Send-Response" 
9 call-back procedure. Then at step lOi, the MARC program 

40 will process this processing request message, after 
fff which at step Hi, MARC sends the message to the client 

15 terminal 10. 



At Step 12 i, MARC 40 returns control from the 
call-back procedure back to the Kerberos Support Library 
34* Then at step 13 i, the KSL 34 prepares any return 
parameters for MARC 40, for example, such as a message 

20 containing secured data. The KSL 34 returns the value 
^^14" (indicating the actual success or failure of the 
authentication process) which will be provided to MARC 40 
via a message sent asynchronously using the MCP's 
DCSEMDHESSAGETOMCS procedure. 

25 Then at step 14i, the KSL 34 returns control to 

the MARC 40 together with any retusnn parameters. Only 
the value of is relevant in this case. 

At step 15i, the Key Distribution Center 22 
(KDC) returns the Authentication Response (AS_Rep 

30 message) over to the Kerberos Support Library 34. This 
can happen anytime after step 7i. 

The KDC 22 decodes the AS^Request message which 
the KSL 34 had sent to it and, assuming its database 
contains appropriate information for the Principal_ID 

35 contained in the message, then builds an AS.Rep message. 
The AS^Rep message contains a Ticket Granting Ticket 
(TOT) and other information related to the data passed in 
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the AS.Request. Most of this latter information, 
including the "^^NONCE", is contained in a token which is 
encrypted using the Principal's shared secret key. This 
key can be generated by trainsforming the data entered on 
5 the logon screen and is shared only between the user (who 
knows the password) and the KDC 22 which holds the 
corresponding key in its database. The KBC 22 uses the 
UDP protocol to return the AS_Rep message to the KSL 34. 

Now at step 16i, the Kerberos Support Library 
10 34 decodes (decrypts) the authorization response and 
performs various verification checks, for example, like 
ip the ^ClockskeW check. The KSL 34 receives the ASJRep 

message from the KBC 22 and matches it to the original 
III request using the fact that it can successfully decrypt 

15 the enczrypted token using the Principal's password and 
that the particularly contained information, especially 
the ^MONCE^, matches what was sent in the ASjRequest 
'h message . 

1^^ Then at step 17 i, the KSL 34 builds a Ticket 

1=^!; 20 Granting Service request (TGS_Req message) for permission 

Q to access the local host service. The KSL 34 creates a 

TGS_Req message requesting a service ticket for the local 
host service. This request includes the TGT returned in 
the earlier AS_Rep message. 
25 At step 18i, the Kerberos Support Library 34 

then sends the TGS^Req message over to the Key 
Distribution Center 22. Again, the UDP protocol is used 
to send the message to port ^^88" at the IP address 
indicated for the KDC 22 serving the realm indicated by 
30 the entered Principal_ID . 

Now at step 19 i, the KDC 22 returns a Ticket 
Granting Service response (TGS_Rep message) over to the 
Kerberos Support Library 34. This can happen anytime 
after step IBi. The KDC 22 decodes the TGS^Req message 
35 which the KSL 34 had sent to it and, ass\iming its 
database contains appropriate information for the service 
contained in the message, then builds a TGS.Rep message. 
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The T6S_Rep xoessage contains a service ticket £or the 
requested service « The KDC 22 uses the UDP protocol to 
return the TGS.Rep message to the KSli 34. 

At step 20i, the Kerberos Support Library 34 
5 will decode/or decirypt the TGS response and perform 
verification checks, such as a Clockskew check. It also 
creates a new KSL-credential- structure to hold 
information pertaining to this particular client (for 
example, PXD and the tickets returned by the KDC 22) • 

10 The KSli 34 also creates parameters to pass over to the 
Generic Security Service 38 (6SS) in order to get a name 
;]! handle corresponding to the client's PID (Personal 

Identification Number) • 
^1 Decoding and decryption of the TGS response 

15 occurs in several stages. First, the encrypted part of 
the message is decrypted using the key which was returned 
in the earlier AS_Rep message and the resulting plain 
text is decoded. The fact that this is possible 
indicates that the message could only have been generated 

20 by the KIX! 22. The KSL 34 has access to the service key 
ip for the local host aiui uses this to decode and decrypt 

the Sezv^ice Ticket in the TGS response. The success of 
this phase indicates that the original client is allowed 
access to appropriate facilities on the local host 

25 machine. Once all of the checks have been con^leted, the 
KSL 34 creates a credential structure which may be used 
in the future if the client atten^ts some f\mction which 
recjuires the established credentials. 

Then at step 21i, the Kerberos Support Library 

30 34 will call the GSS 38 and pass the PID, the PID length 
and its name type. The KSL 34 passes the client's 
Principal_lD, its length, and the name type to the GSS 
38, requesting a name handle which will be used in the 
future to refer to this name. 

35 Then at step 22i, the GSS 38 will process the 

PiD/name type (store PiD/name type). 
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6SS 38 uses the name type to identify the 
mechanism that made the call. 6SS 38 stores the PID and 
the PXD length in its internal heap and a pointer to the 
name in its tables. 
5 At step 23i, the GSS calls the Kerberos Support 

Library 34, KSL 34, to translate the PID into a local 
user code (UC) on the system. The PID and the PID length 
are passed on to the KSL 34. 

At step 24i, the Kerberos Support Library 34 

10 maps the PID to the User Code (UC) and its length, and 
prepares the information to return to the GSS 38. KSL 34 
uses the system procedure ^^USERDATA'' to map the PID to a 
corresponding A-Series USERCODE. This USERCODE is 
converted into the form expected by the GSS 38. The 

15 eicpected form is an upper case identifier in parentheses. 
For example, the USERCODE "^freD" will be converted to 
^(FRED)''. 

At Step 25i, the Kerberos Support Library 34 
returns the User Code /and the length, to the GSS 38. At 

20 step 26i, the GSS 38 stores the User Code (local name) 
/length/ in its internal tables and generates a Name- 
Handle for the name. At step 27 i, the GSS 38 returns the 
generated Name-Handle over to the Kerberos Support 
Libraary 34. At step 28i, the Kerberos Support Library 34 

25 saves the Name-Handle in the KSL-Credential -Structure, 
and then creates the KSL-Credential -Handle for this 
particular structure. 

At step 29i, the Kerberos Support Library 34 
calls the GSS 38 (Mech_Add_Cred) passing the Name-Handle 

30 and the KSL-cred-handle requesting the GSS 38 to create 
its credential information for the client. 

At step 30i, the GSS 38 validates the Name- 
Handle passed in by KSL 34. If the validation succeeds, a 
Credential Handle that corresponds to the Name Handle is 

35 created in the GSS internal tables. The GSS-cred-tag is 
a part of the GSS-cred-handle. 
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Again referring to Fig. 18, at step 31i, the 
6SS 38 will return the GSS-cred-tag to the Kerberos 
Support Library 34. Then, at step 32i, the Kerberos 
Stapport Library 34 will save the GSS-cred-tag in the KSL- 
5 Credential -Structure. At step 33i, the Kerberos Support 
Library 34 will pass the GSS-cred-tag over to the GSS 38 
asking for the GSS-cred-handle. At step 34i, the GSS 38 
will map the GSS-cred-tag to the GSS-cred-handle. Then 
at step 35i, the GSS 38 returns the GSS-cred-handle back 
10 to the Kerberos Support Library 34* At step 36i, the 
Kerberos Support Library 34 builds a message to inform 
CI MARC 40 that the Kerberos authentication has successfully 

coi^pleted (the message incl\ides the GSS-cred-handle) • 

At step 37i, the Kerberos Support Library 34 
15 calls the Master Control Program 60 (MCP) 
(DCSENDMESSAGBTOCOMS) , thus passing to MARC the message. 

At step 38i, there is a cc»mminication from the 
p MCP 60 over to the COMS program 42 as was described in 

1^ the co-pending U.S. patent application. Serial 09/026,746 

hp 

20 entitled "^^Kxpedited Message Control for Sirnchronous 
Response in a Kerberos Domain'', which is incorporated 
herein by reference. 

At step 39i, the Master Control Program 60 
(MCP) puts in an ^intercomq" request for COMS 42. The 
25 response is inserted ultimately by using the INSERT 
constructed into an intercoroq managed by the MCP 60. 
COMS 42 is notified of such an INSERTion via a queue 
event mechanism. 

Then at step 40i, the communication management 
30 system COMS 42 recognizes this queued message as a 
message for MZ^C 40 if the message has a mutually agreed 
upon value in the first word of the Header. At step 41, 
COMS 42 then sends a message over to MARC 40 by calling a 
procedure and passing in a mutually known function code. 
35 Thus signals MARC 40 that this message is from Kerberos. 

At step 42i, MARC recognizes an asynchronous 
message from the Kerberos Support Library 34, then 
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verifies it and then extracts the 6SS-cred-handle. At 
step 43i, MARC 40 calls the GSS 38 (ASP- 
h£m.dle_intemal.XD) passing the GSS -cred-handle. At step 
44i, the 6SS 38 maps the GSS-cred-handle to a User Code 
5 (UC) • 6SS 38 has links that relate the Credential Handle 
to a Name Handle. The Name Handle has the user code 
information in the GSS tables. 

Then at step 45i, the GSS 38 returns the User 
Code (UC) over to lyiARC 40. At step 46i, MARC 40 begins 

10 to create a session for the User. At step 47i, MARC 40 
then calls the MCP 60 (User data file 72) in order to get 
the User's attributes. At step 48 i, the MCP 60 reads the 
UserCode attributes from the USERDATAFILE 72. These 
attributes contain specific infozmation unique for a 

15 given client or user. These attributes, however, are not 
germane to the overall description of this mechanism. 

Then at step 49 i, the MCP 60 returns the 
attribute information back to MARC 40. MARC is passed 
this information as a return to an entry point call. 

20 Then at step 50i, MARC 40 completes the 

creation of the User's session. At step 51i, then MARC 
40 passes the session information and the GSS -cred-handle 
over to the MCP 60 via the MCS_riogger. 

At step 52i, the Master Control Program 60 

25 (MCP) Writes to the Log file 36. Specific information is 
recorded in the log, none of which is considered 
^^sensitive"^ client /user information. 

At step 53i , the MCP 60 calls the GSS 3 8 
(MCP_ADD.Credential) passing the GSS-cred-hemdle and the 

30 mix number. 

At step 54i, the GSS 38 associates the mix 
number with the GSS-cred-handle and stores it in its own 
tables. Then at step 55i, the GSS 38 returns the control 
back to the MARC 40. At step 56i, the MCP 60 returns the 

35 control back to MARC 40. This is a release of a call 
back to the original re<zuestor. 
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Then at step 57 i, the MARC program 40 generates 
default home screen for the client User 10. If the 
client has been authenticated^ the client is sent (or 
presented with) their home or default screen (menu- 
5 graph) • In the event of a failed attempt, an error 
message or screen will then be returned. 

Then at step 58i, MARC 40 sends the default 
home screen (or the rejection screen) to the client 
terminal waiting for input to the screen. Like step li, 
10 this screen is sent to the client via a non-specific 
network protocol. The client User now has his response, 
and knows he is or is not authenticated. 

Described herein has been a software mechanism 
which authenticates a client (previously non- 
15 authenticated) or a non-preauthenticated Principal 
operating in a Kerberos domain or realm through use of an 
asynchronous message process. The validation of the 
client's ability to participate is performed by a 
Kerberos Server. The communications between the client 
20 and the server are performed by using various types of 
messages and various protocols, such as the 
Communications Management System 42, the Menu-Assisted 
Resource Control system 40, the Master Control Program 
60, the Generic Security Service 38, and the Kerberos 
25 Support Library 34, together with the Kerberos Server 20. 
If the authentication mechanism was only able to process 
a single request for authentication to completion, there 
would normally exist a long wait or bottleneck while 
various other requests were being processed. However, by 
30 utilizing an asynchronous mechanism and its subtasks in 
various states, the authentication can be processed 
without having to wait for any one single request to be 
con^letely finished. Thus, there is provided a 
facilitation of completed authentication processing of 
35 multiple requests from non-preauthenticated multiple 
clients, each of which have been requesting Kerberos 
authentication . 
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While a particular example of the above- 
mentioned method emd system has been described for 
effectuating a non-preauthenticated Kerberos Logon using 
an asynchronous message mechanism, other embodiments may 
also be implemented which still are encompassed by the 
present invention, which invention is to be understood as 
being defined by the following claims. 
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WHAT IS CLAIMED IS; 

1: A system for enabling asynchronous 

authentication of a non-preauthenticated client-User 
means in a Kerberos domain servicing multiple requesting 
5 non-preauthenticated clients while eliminating any delays 
due to multiple concurrent authentication requests, said 
system comprising: 

(a) client-user means (10) for requesting 
authentication from a client-server means (13); 

10 (b) client-server meems (13) for communicating 

with a Kerberos server means (20) for 
developing a specific set of credentials for 
said single client requesting authentication; 

(c) said Kerberos server means (20) for 
15 developing an asynchronous authentication 

response and a Ticket Granting Service to said 
client-server means (13) • 
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2: The system of Claim 1 wherein said client-User 

means (10) includes: 



(al) multiple client -Users who may 
concurrently seek authorization to utilize 
said client-server. 

3. The system of claim 1 wherein said Kerberos 

server means (20) includes: 

(cl) means to return an authentication 
response to said client-Server means; 

(c2) means to return a Ticket Granting 
Searvice signal to said client- server 
means . 



awk\appl\041470L.doc 



80 

4: The system of claim 1 wherein said client- 

server means includes: 

(bl) communication means (MARC40, COMS42} 
for exchanging information between a 
requesting principal or client-User, a 
Master Control Program, a General Security 
Service Library (GSS38), and a Kerberos 
Support Library (KSL34); 

(b2) said Master Control Program (60) for 
controlling said communication means, said 
General Security Service Library and said 
Kerberos Support Library (34); 

(b3) said General Security Service Library 
(GSS38) providing multiple threads for 
handling multiple concurrent reciuests for 
authentication; 

(b4) said Kerberos Support Library (34) 
for developing and storing specific 
authentication credentials for each 
validated client-User authentication 
request • 



5 5 The system of claim 4 wherein said Kerberos 

Support Library (34) includes: 

(b4a) means for accessing said 
Kerberos Server means (20) to acquire 
an authentication response and a 
Ticket Granting Service. 
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6: A secure message transmission system in a 

Kerberos environment which permits a client-user to 
operate in a network for authentication request 
transmittal and message response without suspending 
client service when a Kerberos Server has not yet 
responded to an earlier request for an authentication 
message code signal, said system comprising: 

(a) client- terminal means (10) to indicate an 
original request for validation of an 
authentication message signal from a Kerberos 
Server (20); 

(b) program means (MARC 40 and COMS 42), under 
control of a Master Control Program (MCF60), 
for transmitting requests for service to a 
Kerberos Support Library (34) , a General 
Security Service Library (38) and Kerberos 
Server (20) for the return of an authentication 
response message to said client terminal means 
(10) from credential information placed in said 
General Security Service Library; 

(c) means for enabling said Kerberos Support 
Library (34) to elicit authentication 
information and Ticket Granting Service frcOT 
said Kerberos Server (20) for deposit as 
validating credential data in said General 
Security Service Library (38). 
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7: A method for asynchronous authentication of a 

non-preauthentlcated originating terminal in a Kerberos 
domain, said authentication occurring without delay due 
to other concurrent requests for authentication by other 
5 terminals such as client-Users and principals, said 
method comprising the steps of: 

(a) originating a request, to a client -server, 
for authentication by a non-preauthenticated 
terminal; 

10 (b) processing said originating re<zuest and 

other originating requests concurrently; 

(c) responding back asynchronously by said 
client-server to authenticate the validity of 
said original requesting terminal without any 
15 delays due to other concurrent requests for 

authentication • 
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8: The method of claim 7 wherein step (a) includes 

the step of: 

(al) originating concurrent multiple requests 
for authentication from multiple client-Users 
and principals. 



9: The method of claim 7 wherein step (b) includes 

the steps of: 

(bl) developing a set of identifying 
credentials for said originating terminal; 

(b2) asynchronously validating said originating 
terminal for use of a Kerberos domain. 
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10: The method of claim 9 wherein step (bl) 

includes the steps of: 

(bla) requesting, via a communication 
means (MARC 40, COM942), xinder 
control of a Master Control Program 
(MCP60), a Kerberos Support Library 
(34), and a Kerberos Server (20) for 
credentials and a session key; 

(bib) creating a credential structure 
by said Kerberos Support Library (34) 
to identify said originating terminal 
and provide a Ticket Granting 
Service; 

(blc ) generating, by a General 
Security Service Library (GSS 38), of 
a Name-Handle and GSS Credential Tag 
that identifies the originating 
terminal to said GSS (38) axid to said 
Kerberos Support Library (34); 

(bid) generating a message, by said 
Kerberos Support Library (34), to 
inform said communication meeuis (MARC 
40, COMS42) that the Kerberos 
authentication cycle has been 
successfully completed. 
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11; The method of claim 9 wherein step (bl) 

includes the steps of: 

(bla) processing concurrent authentication 
recxuests via multi -threaded processing 
means to develop a specific credential for 
each originating terminal; 

(bib) conveying said first completed 
authentication request to said Kerberos 
Support Library (34) and said 
communication means (MARC 40, COXIS42). 



12: The method of claim 7 wherein step (c) includes 

the steps of: 

(cl) utilizing said communication means (ISARC 
40, CO&1S42) to transmit an authentication 
signal from said Kerberos Support Libraary (34) 
to said originating terminal. 
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13: Zn a network wherein multiple client-terminals 

communicate with a client- server (13)^ having a Kerberos 
Support Library (34)^ and communicate with a 
communications means (MARC 40^ COMS 42), a General 
Security Service Library (38) and said client-searver for 
accessing response information from a Kerberos server 
(20), a method for enabling a requesting client -terminal 
to receive an authentication response message 
asynchronously from said Kerberos Server (20) comprising 
the steps of: 

(a) initiating an authentication command 
regiiest by a reciuesting client-terminal; 

(b) utilizing a communication management 
system, under control at a Master Control 
Program (MCP60), using a communication means 
having a communication management program (COMS 
42) and menu assisted resource control program 
(MARC 40) to communicate said command request 
to said Kerberos Server (20) via said Kerberos 
Support Library ( 34 ) and to receive a Kerberos 
response message for credential processing by 
said General Security Services Library (38) 
which is then conveyed by said communication 
means (40, 42) to said requesting client- 
terminal . 
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14: The method of claim 13 which includes the step 

of: 

(c) Terminating the session between said 
client-terminal (10) and said Kerberos Support 
Library (34) once the authentication request 
response has been transmitted from said General 
Security Library (38), thus allowing said 
client-server (13) to process other 
authentication reciuests . 

15: The method of claim 13 wherein step (b) 

includes the step of: 

(bl) initiating an error message by said 
Kerberos Support Library (34) when a failure in 
authentication has been recognized; 

(b2) requesting, via said error message, that 
said client-Terminal (b) should initiate a log- 
on. 
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